When investigating a Linux system, knowing the process name is not enough. The analyst also needs to understand where the executable came from, which user launched it, what permissions it had, which files it accessed and whether it established persistence or network communication.
A process running from /tmp has a different context from a process installed through the system package manager. A new entry in /etc/sudoers has a different impact from a temporary application file. A process whose executable has already been deleted deserves a different investigation from a known service running from its expected location.
None of these observations proves that a system has been compromised. They provide direction.
This is the foundation of the Learn Normal to Detect Abnormal series. Before identifying meaningful deviations, analysts need to understand how the operating system behaves under normal conditions.
Linux is everywhere. It powers web servers, cloud workloads, containers, database servers, CI/CD infrastructure, network appliances, security products and IoT devices.
An analyst who is comfortable only with Windows may have a significant visibility gap when an alert involves a Linux server, a container host or a cloud workload.
The objective is not to become a Linux administrator before beginning an investigation. The objective is to understand the parts of the operating system that provide security context.
Where are user accounts defined? Where are authentication events stored? Which directories are writable by ordinary users? How are scheduled commands configured? Where can we inspect a running process after its executable has been deleted?
Once those questions become familiar, Linux investigations become much less intimidating.
Windows separates storage using drive letters such as C: and D:. Linux uses one unified directory tree beginning at the root directory:
/Important directories branch from this location. Their organization is influenced by the Filesystem Hierarchy Standard, commonly known as FHS. The exact structure may still vary between distributions, versions and installed applications.
Linux also exposes a large amount of system state through files and virtual file systems. Processes, devices, kernel information and network related data can all be represented through paths.
This is useful during an investigation because valuable information can often be collected without a graphical security interface. If an analyst knows where to look, the file system becomes a map of the operating system.
A path can increase or reduce suspicion, but it cannot independently prove legitimacy or compromise.
An unknown executable under /tmp may be suspicious. It may also belong to a legitimate installer. A file under /usr/bin may be expected, but a trusted location does not guarantee that the file has not been replaced or abused.
The path must be correlated with the owner, group, permissions, timestamps, file type, SHA 256 hash, parent process, command line, user context, persistence and network activity.
The strongest findings usually contain contradictions. A service account suddenly receives an interactive shell. A temporary executable establishes permanent persistence. A system service launches a file from a user writable directory. A process continues running after its executable has been deleted and maintains an external connection.
Those contradictions are where the investigation becomes valuable.
The /etc directory contains system wide configuration for the operating system and installed services. Changes in this location may affect accounts, authentication, privileges, networking, services and scheduled execution.
Files under /etc change during legitimate administration, software installation, package updates and automated configuration management. A recent modification is therefore not automatically malicious.
The analyst should determine which file changed, which process made the change, which user was responsible and whether the activity matches an approved administrative task.
The /etc/passwd file contains information about local user and service accounts. Each entry normally includes the username, user identifier, group identifier, account description, home directory and login shell.
The file can be reviewed with:
cat /etc/passwdDuring an investigation, look for newly created accounts, unexpected interactive shells, unusual home directories and accounts with user identifier 0.
The root account normally uses UID 0. Another account with the same identifier effectively has root level identity and should be investigated immediately unless there is a documented and exceptional reason for its existence.
Service accounts frequently use shells such as:
/usr/sbin/nologin
/bin/falseThis prevents ordinary interactive login. A service account unexpectedly changed to /bin/bash or another interactive shell may indicate administrative reconfiguration or an attempt to obtain persistent access.
Do not judge the account only by its name. An attacker may create an account that resembles a legitimate service or system user. Review the UID, shell, home directory, creation context and subsequent authentication activity.
Modern Linux systems generally store protected password related information in /etc/shadow rather than /etc/passwd. The file contains password hashes and information related to password aging and expiration.
Access is restricted because obtaining the hashes may allow an attacker to perform offline password cracking.
An unexpected process reading /etc/shadow is an important credential access signal, but it is not automatically malicious. Legitimate authentication components, password management tools, identity products and backup processes may access the file with elevated privileges.
The relevant questions are:
Which process accessed the file? Which user launched it? What privileges did it have? Was the access expected for that application? What happened before and after the access?
A nonprivileged process should not normally be able to read /etc/shadow. Successful access from such a context may indicate a permissions problem, a vulnerability or privileges that were obtained earlier in the attack.
The /etc/sudoers file and additional files under /etc/sudoers.d define which users and groups may execute commands with elevated privileges through sudo.
An unauthorized modification may provide persistent privileged access without creating an obviously suspicious process that runs continuously.
Review the metadata of these locations with:
ls -la /etc/sudoers /etc/sudoers.dWhen authorized to inspect the content, review it carefully:
sudo cat /etc/sudoers
sudo ls -la /etc/sudoers.dPrioritize new NOPASSWD rules, commands that allow shell execution, unexpected users receiving broad permissions and rules that effectively provide unrestricted root access.
A recent modification during the suspected compromise window is a critical finding, but the investigation must still consider configuration management, onboarding, maintenance and other approved changes.
Linux uses cron to execute commands and scripts according to a schedule. Relevant locations may include:
/etc/crontab
/etc/cron.d/
/etc/cron.hourly/
/etc/cron.daily/
/var/spool/cron/
/var/spool/cron/crontabs/The exact locations depend on the distribution.
Cron is used legitimately for maintenance, backups, monitoring, log rotation and application tasks. It can also be used to repeatedly execute a malicious file, download content or restore access after a process has been terminated.
A cron entry becomes more interesting when it runs every few minutes, invokes a shell, uses curl or wget, executes encoded content or launches a file from /tmp, /var/tmp, /dev/shm or a user directory.
Do not evaluate the cron command in isolation. Identify the owner, execution schedule, referenced script, file permissions and network destinations.
The /var directory contains variable data that changes during system operation. This includes logs, application caches, mail queues, service data and other runtime content.
For analysts, /var/log is one of the most important locations. The available files depend on the Linux distribution, logging configuration and installed services.
Modern systems may also store important events in the systemd journal, meaning that the evidence may not exist only as traditional text files under /var/log.
On Debian and Ubuntu based systems, authentication activity is commonly stored in:
/var/log/auth.logOn RHEL based distributions, including systems such as Rocky Linux and AlmaLinux, the relevant file is commonly:
/var/log/secureThese logs may contain failed and successful SSH logins, sudo usage, PAM activity and session information.
They should not be described as a direct equivalent of Windows process creation telemetry. Authentication logs primarily explain identity and privilege activity. Detailed process creation and system call visibility may require auditd, an EDR platform or another telemetry source.
Useful hunting patterns include repeated failed SSH logins, attempts against many accounts, a successful login after repeated failures, authentication from an unusual address and sudo activity performed by a user who does not normally administer the system.
Always consider automation, vulnerability scanners, management platforms and shared administrative infrastructure before classifying the activity.
On systems using systemd, journalctl provides access to the system journal.
A general review can begin with:
journalctlA specific time range can be selected:
journalctl --since "2026-08-30 10:00:00"
journalctl --until "2026-08-30 12:00:00"SSH events may be available under ssh or sshd, depending on the distribution:
journalctl -u ssh
journalctl -u sshdSudo related activity may be queried with:
journalctl _COMM=sudoThe available data and retention depend on configuration. An empty result does not prove that the event did not occur. The service name may differ, the event may have been stored elsewhere or the relevant data may already have expired.
The Linux Audit Framework can record file access, system calls, process execution, privilege related activity and changes to sensitive configuration.
When auditd is installed and properly configured, its events are commonly stored in:
/var/log/audit/audit.logCheck whether the service is running:
systemctl status auditdReview active audit rules:
auditctl -lSearches may include:
ausearch -f /etc/shadow
ausearch -f /etc/sudoers
ausearch -m USER_LOGIN
ausearch -m USER_CMDThe presence of auditd does not mean that every important action is being recorded. Its value depends on the rules that were active when the activity occurred.
If no rule monitored access to /etc/shadow, the absence of an audit event does not prove that the file was never accessed.
The /tmp directory is used for temporary files and is commonly writable by local users. The operating system, applications, installers and user sessions all use it during normal operation.
A file in /tmp is not automatically suspicious.
Execution from /tmp requires context.
A legitimate installation process may extract and execute a temporary component from /tmp. The behavior may be expected when the parent process belongs to a known package manager or installer, the file matches an approved package and no suspicious persistence or network activity follows.
An unknown executable in /tmp becomes more significant when it has a random name, runs with elevated privileges, was downloaded with curl or wget, creates persistence, establishes an external connection or deletes itself shortly after execution.
Initial inspection may include:
ls -la /tmp
find /tmp -type f -lsCommands such as find can produce a large amount of output on busy systems. Consider the performance and operational impact before running broad searches in production.
The /dev/shm location commonly represents a tmpfs file system used for shared memory and temporary content.
Attackers may use it to stage or execute short lived files because it is often writable and receives less attention than traditional application directories.
It is sometimes described as a location that guarantees completely diskless execution. That description is not always technically precise. Tmpfs is primarily memory backed, but it may interact with swap depending on the system configuration. The file is also accessible through a normal path while it exists.
The more useful security point is that short lived content under /dev/shm may receive less visibility from tools focused on scanning persistent storage.
Initial inspection may include:
ls -la /dev/shm
find /dev/shm -type f -lsPrioritize unknown executable content, scripts with random names, files that disappear shortly after execution and processes that establish external network communication.
Do not classify ordinary shared memory files as malicious simply because they are located under /dev/shm.
The /proc directory is a virtual file system that exposes information about the kernel and running processes.
Every active process has a directory named after its process identifier:
/proc/<PID>/The process command line can be reviewed with:
cat /proc/<PID>/cmdlineBecause the arguments are separated by null characters, the following command often produces a more readable result:
tr '\0' ' ' < /proc/<PID>/cmdlineThe executable associated with the process can be inspected through:
ls -la /proc/<PID>/exeThe current working directory is available through:
ls -la /proc/<PID>/cwdOpen file descriptors can be reviewed through:
ls -la /proc/<PID>/fdMemory mappings may be available through:
cat /proc/<PID>/mapsAccess depends on permissions, security controls and system configuration. An analyst should not assume that every process can be fully inspected from an unprivileged account.
On Linux, a running process may continue after its executable has been removed from the directory. The process already holds a reference to the file, so deleting its directory entry does not necessarily terminate the process.
The /proc link may then show:
/proc/1842/exe -> /tmp/.update (deleted)This is a valuable investigative signal, especially when the process originated from /tmp or /dev/shm and maintains an unknown external connection.
It is not automatic proof of malware. A legitimate package update may replace or remove a binary while an older process remains active.
The analyst should determine whether a package update occurred, which user launched the process, what the process is doing and whether its network and persistence behavior matches the expected application.
Running process identifiers can be listed with:
ls /proc | grep -E '^[0-9]+$'Commands such as ps are usually more convenient for an initial overview:
ps aux
ps -efA suspicious process should be correlated with its network connections.
Useful commands may include:
ss -plant
ss -panu
lsof -iSome process details require elevated privileges.
Review the local and remote address, port, connection state, process identifier and program name. An unknown process from /tmp or /dev/shm that maintains an external connection is more significant than a temporary file that was never executed.
Also consider the role of the system. An outbound connection may be normal for a web proxy or update server but unusual for an isolated database server.
A public IP address is not automatically malicious, and a connection to a known cloud provider is not automatically safe. Attackers regularly use legitimate hosting and cloud platforms.
An attacker does not need to create a new user account to maintain access. A public key can be added to the authorized_keys file of an existing user.
Relevant locations include:
/home/<username>/.ssh/authorized_keys
/root/.ssh/authorized_keysReview the directory metadata with:
ls -la /home/<username>/.ssh
ls -la /root/.sshCheck the owner, permissions, modification time and content. Determine whether the key belongs to the organization and whether the change was expected.
A newly added key during the suspected compromise period is an important finding. Its significance increases when it follows an unusual login, sudo activity or modification of account privileges.
Files such as .bashrc, .bash_profile and .profile can execute commands when a user logs in or starts a shell.
Relevant examples include:
/home/<username>/.bashrc
/home/<username>/.bash_profile
/home/<username>/.profile
/root/.bashrc
/root/.profileThese files are legitimately modified during administration, development tool installation and customization of the user environment.
Suspicion increases when they contain commands that download content, launch hidden processes, execute files from /tmp or /dev/shm, connect to external destinations or contain encoded and intentionally difficult to read instructions.
Many modern Linux distributions use systemd to manage services. An attacker may create or modify a service so that a malicious process starts during boot or restarts after termination.
Relevant locations may include:
/etc/systemd/system/
/usr/lib/systemd/system/
/lib/systemd/system/Locally created and customized service definitions are commonly stored under /etc/systemd/system.
Useful commands include:
find /etc/systemd/system -type f -ls
systemctl list-unit-files --type=service
systemctl list-units --type=serviceInvestigate newly created services with names that imitate legitimate system components, ExecStart values pointing to /tmp, /dev/shm or user directories, shell execution and unknown external communication.
Legitimate software installation can also create services. Correlate the service with package activity, approved changes, file ownership and the expected role of the system.
Shell history may provide useful context during an investigation.
Common locations include:
/home/<username>/.bash_history
/root/.bash_history
/home/<username>/.zsh_historyCommand history is not a complete or reliable security record. A user or attacker can disable history, modify the file, delete entries or use a shell that does not record commands in the expected location.
Commands found in history can support an investigation. The absence of suspicious commands does not prove that the activity never occurred.
Begin by recording the hostname, username, timestamp, process identifier and complete executable path. Preserve the original values before moving deeper into the investigation.
Inspect the complete command line, parent process, working directory and open file descriptors.
Check the file owner, group, permissions and timestamps. Calculate the SHA 256 hash and determine whether the file belongs to an installed package.
Check whether the executable was deleted while the process remained active. Review the /proc entry and determine what the process is currently doing.
Inspect network connections, remote addresses, domains and ports. Identify whether the process is listening for connections or communicating externally.
Search for persistence through cron, systemd services, SSH keys and shell configuration files.
Review changes to /etc/passwd, /etc/shadow, /etc/sudoers and /etc/sudoers.d.
Examine authentication logs, the systemd journal and auditd events when available.
Finally, compare the activity with package updates, automation, configuration management, maintenance and administrator actions.
Before uploading an unknown file to an external analysis service, check the organization’s policy and data classification. Verifying only the SHA 256 hash is usually a safer initial step than uploading the file itself.
An unknown process from /tmp or /dev/shm that establishes an external connection should receive increased priority.
A process with a deleted executable becomes more significant when it remains active, communicates externally or runs with elevated privileges.
Unauthorized modifications to sudoers configuration, a new account with UID 0 and an unexpected SSH key added to a privileged account require immediate investigation.
A new cron job or systemd service becomes more significant when it launches an unknown file, repeatedly downloads content or executes from a user writable location.
An attempt to read /etc/shadow from an unexpected process may indicate credential access. Security log deletion or sudden audit service modification may indicate an attempt to remove evidence.
A service account that suddenly receives an interactive shell or new privileges should be correlated with authentication and administrative activity.
Rarity alone is not enough. An unknown process becomes more meaningful when several suspicious behaviors occur together.
A practical hunt can search for process execution from temporary and commonly writable locations.
The following is generic search logic. Field names must be adapted to the SIEM or EDR platform and the organization’s data normalization:
process_path STARTS WITH ANY (
"/tmp/",
"/dev/shm/",
"/var/tmp/"
)
AND process_action = "execution"The results should be enriched with the user, parent process, command line, SHA 256 hash, file prevalence and network connections.
Another hunt can search for changes to sensitive files and directories:
file_path IN (
"/etc/passwd",
"/etc/shadow",
"/etc/sudoers"
)
OR file_path STARTS WITH ANY (
"/etc/sudoers.d/",
"/etc/cron.d/",
"/etc/systemd/system/"
)
AND file_action IN (
"create",
"modify",
"delete",
"permission_change"
)This logic produces investigation candidates. It does not prove compromise.
Configuration management systems, package installations and administrators may legitimately modify the same locations. The analyst must identify the process, account, source host, timing and approved change associated with the modification.
A broad hunting query should not automatically become a production alert.
Execution from /tmp alone may produce many legitimate results. A more useful detection may combine execution from /tmp with an unknown or low prevalence hash, elevated privileges, an unusual parent process, external communication and rapid file deletion.
A modification to /etc/sudoers may be expected when performed by an approved configuration management process. The same modification performed through a shell launched by a web service should receive a much higher priority.
Use the hunt to identify which combinations separate legitimate administration from risky behavior. Then define the required data sources, time window, asset context and narrow exceptions.
Test the detection against historical data before enabling production alerts. Do not globally exclude an entire directory, user group or administrative tool simply because it appears frequently.
The Linux file system gives the analyst a map, but the map does not make the decision.
The /etc directory contains critical configuration, but changes there may be legitimate. The /tmp and /dev/shm directories are attractive to attackers, but legitimate software uses them every day. A deleted executable may indicate an attempt to remove evidence, but it may also result from a package update.
The strongest findings come from correlation.
A new SSH key appears after an unusual login. A service account receives an interactive shell and then uses sudo. A process runs from /dev/shm, connects externally and creates a systemd service. A web server launches a shell that modifies /etc/sudoers.
Each event provides part of the story. The sequence provides the context needed to understand what happened.
Learn normal to detect abnormal. Then connect the abnormal behavior with enough technical and operational context to determine whether it represents administration, misconfiguration or compromise.
When investigating a Windows endpoint, the file name is only the beginning. A process called svchost.exe may be a normal Windows component, a copied binary, a renamed payload or a malicious file created to resemble something familiar. The name gives us a clue. The complete path gives us context.
This is why understanding the Windows file system matters in security operations. An analyst does not need to memorize every directory or become a digital forensics specialist before investigating endpoint activity. However, the analyst should understand what normally belongs in the most important Windows locations, what may legitimately execute from user directories and which combinations of path, process and behavior deserve further investigation.
The basic principle is simple:
Normal does not automatically mean safe. Abnormal does not automatically mean malicious. An abnormal path or process relationship is a reason to investigate and correlate.
A suspicious path is not proof of compromise. A trusted path is not proof of legitimacy. The most reliable conclusions come from combining the file location with the process name, digital signature, publisher, hash, command line, parent process, user context, persistence activity and network communication.
Windows file system knowledge is useful during alert triage, threat hunting, incident response and digital forensics, but each activity uses it differently.
During alert triage, the analyst may receive an alert for a process executing from an unusual location and use the path to determine whether the event requires further investigation.
During threat hunting, the analyst can proactively search for known Windows process names executing from unexpected directories, unknown executables running from temporary locations or persistence mechanisms referencing user writable paths.
During incident response, the same knowledge helps establish scope, identify related payloads and understand how the attacker maintained access.
Digital forensics goes deeper into artifacts such as Prefetch, Amcache, deleted files, registry hives and file system timestamps. Those artifacts can support a threat hunt, but they are usually used when additional validation or historical reconstruction is required.
The boundary between these activities is not always strict. A threat hunt may uncover suspicious execution, continue into endpoint analysis and eventually become a full incident investigation.
A process name without its path is incomplete evidence.
Consider the following process:
svchost.exeThat name is associated with a legitimate Windows component. However, these two paths do not have the same analytical meaning:
C:\Windows\System32\svchost.exe
C:\Users\Public\svchost.exeThe first path is expected for the legitimate Windows Service Host process. The second path uses a legitimate Windows process name in a user writable directory. That is a strong masquerading signal and should be investigated.
This still does not mean that the second file is automatically malicious. It means that the process name does not match the expected location and that additional evidence is required.
The analyst should immediately inspect the digital signature, publisher, hash, parent process, command line, user, file creation time and network activity. The next question is not simply whether the path looks wrong. The next question is what the file did.
On a 64 bit Windows system, C:\Windows\System32 contains core 64 bit Windows binaries and libraries. Processes such as lsass.exe, services.exe, winlogon.exe, csrss.exe and svchost.exe are normally associated with this directory.
When one of these names appears in a different location, the path becomes a high value investigative signal.
Expected:
C:\Windows\System32\lsass.exe
Requires investigation:
C:\Users\<username>\AppData\Roaming\lsass.exeThe second file may be attempting to imitate the Local Security Authority Subsystem Service. A user who sees the process name in a task list may assume that it is legitimate. A detection based only on the process name may make the same mistake.
At the same time, a file located in System32 should not be trusted automatically. Attackers may abuse legitimate signed binaries, load a malicious DLL through a trusted process or place malicious content in a location that appears reliable. Permissions may have been modified, a vulnerable driver may be present or a legitimate application may have been manipulated.
The directory reduces or increases suspicion, but behavior determines the final assessment.
The name C:\Windows\SysWOW64 causes confusion because it contains 32 bit Windows components on a 64 bit operating system. Meanwhile, System32 contains the 64 bit components.
The presence of a process in SysWOW64 is not automatically suspicious. A legitimate 32 bit application may use components from this directory.
What matters is whether the process belongs there, whether it has a valid and expected signature, which arguments were used, which process launched it and what it did afterward.
An unknown component, an unexpected child process or unusual external communication may justify further investigation. The directory name alone does not.
C:\Program Files is normally used for 64 bit installed applications. C:\Program Files (x86) is normally used for 32 bit applications on a 64 bit system.
These locations usually provide stronger application context than a temporary or user controlled directory. An installed business application should normally have a recognizable directory structure, a known publisher and files that belong to the same product.
During an investigation, check whether the directory name matches the application, whether the executable is signed by the expected publisher and whether the same file exists on other endpoints where the application is installed.
A directory under Program Files should receive additional attention when it has a randomly generated name, contains an unknown executable, imitates a known product or communicates with a destination unrelated to the application’s purpose.
An attacker may also place a malicious DLL next to a legitimate executable and rely on the application’s DLL search order to load it. In that situation, the main executable may be signed and stored in Program Files while the loaded DLL is the actual malicious component.
C:\Users\<username>\ contains the user profile, documents, downloads and application data associated with an account. Many legitimate applications store data or execute components from the user profile because they are installed without administrative privileges or maintain settings separately for each user.
This means that execution from a user profile is not automatically malicious.
The important question is whether the process and its location make sense together.
A collaboration application running from an expected AppData directory may be normal. A process called services.exe running from the same user profile is not expected Windows behavior.
The user profile also gives the analyst useful context about how a file may have arrived. A file located in Downloads may have been downloaded through a browser. A file in a temporary Outlook location may have originated from an email attachment. A file in AppData may have been created by an application, an installer or another process.
Do not stop at the directory. Trace the origin of the file.
AppData\Local and AppData\Roaming are frequently treated as suspicious in low quality detection rules. That creates unnecessary alerts because many legitimate applications use these directories.
Browsers, communication applications, software updaters and products installed for only one user may legitimately execute from AppData. The presence of an executable in AppData is therefore not enough to classify it as malicious.
The analyst should inspect the directory structure, publisher, signature, prevalence and process chain.
This path may be expected:
C:\Users\<username>\AppData\Local\VendorName\ApplicationName\application.exeThis path requires more attention:
C:\Users\<username>\AppData\Roaming\kqzpt\services.exeThe second example combines a randomly named directory with a file that imitates a Windows system process. Suspicion increases further if the file is unsigned, rarely seen, launched after an attachment was opened or connected to a newly observed domain.
AppData is also frequently used for persistence because a standard user can write to it. A file in AppData referenced by a Run key, Startup folder, scheduled task or another autostart mechanism deserves contextual investigation.
Downloads and Desktop commonly contain files saved by users. Documents, images, archives and installers may all appear there during normal work.
The risk increases when executable or script content is launched directly from these locations, especially when the file arrived through email, a browser download, a shared link or removable media.
Relevant extensions include .exe, .msi, .js, .vbs, .hta, .lnk, .iso and .img. These file types are not automatically malicious, but their origin and execution chain should be understood.
Double extensions also deserve attention:
C:\Users\<username>\Downloads\Invoice.pdf.exeThe file may be attempting to appear as a PDF document while its actual extension is executable. Whether the full extension is visible to the user depends on the Windows configuration and how the file was presented.
C:\Users\Public is used for content shared between users and may be required by legitimate applications. It is also attractive for attackers because files stored there may be accessible to multiple accounts.
A remote access utility, payload, archive containing collected data or system process name inside the Public directory should be correlated with the user, parent process, creation source and subsequent activity.
C:\ProgramData stores application data and configuration shared across users. Security agents, backup products, management tools and other business applications commonly use it.
ProgramData is not suspicious by default. However, it can also be used to hide payloads or persistence components because it is less visible to many users and its contents vary between endpoints.
Investigate unknown executables, hidden files, randomly named directories and content that does not belong to an installed product.
The path should make sense in relation to the software inventory. If a directory claims to belong to Microsoft, an updater or a security product, verify that the publisher, signature and file metadata support that claim.
Files in temporary directories are normal. Windows and applications regularly use temporary locations for logs, extracted installation resources, update data, browser content and files that are needed only for a short period.
The presence of a file in Temp is therefore not automatically suspicious.
The more useful question is whether executable content ran from Temp and what happened around that execution.
A legitimate updater may temporarily extract and launch a signed component from one of these locations:
C:\Windows\Temp\
C:\Users\<username>\AppData\Local\Temp\That behavior may be expected when the parent process is a known updater, the file is signed by the correct publisher, the command line matches the installation activity and no unusual persistence or network behavior follows.
An unknown executable launched from Temp requires more attention. Priority increases when the file is unsigned, exists only briefly, uses a random name, is launched by an Office application or browser, connects to an external destination, creates persistence or deletes itself after execution.
The same logic applies to scripts and other executable components such as .dll, .ps1, .bat, .cmd, .vbs, .js and .hta files.
This process chain would be a high value candidate for investigation:
OUTLOOK.EXE
→ WINWORD.EXE
→ powershell.exe
→ C:\Users\<username>\AppData\Local\Temp\update.exe
→ External network connectionNo single element in this chain proves malicious intent. Together, they describe a sequence that is difficult to explain as ordinary document activity.
MITRE ATT&CK technique T1036 covers masquerading. Subtechnique T1036.005, Match Legitimate Resource Name or Location, describes adversaries using names or locations that resemble legitimate resources.
A common example is a system process name used outside its expected directory:
Expected:
C:\Windows\System32\services.exe
Suspicious:
C:\ProgramData\MicrosoftUpdate\services.exeThe directory name MicrosoftUpdate may also have been chosen to look trustworthy. The attacker is not only imitating a file name. The attacker is creating an entire path designed to survive a quick review.
More advanced cases may involve a malicious file placed in a trusted location, a copied legitimate binary, DLL side loading or the abuse of a valid signed application. This is why path based hunting should generate candidates for investigation rather than automatic conclusions.
A path tells us where a file executed. The process tree helps explain how it executed.
Some process relationships deserve priority because they are frequently associated with document abuse, script execution, web shells, database server abuse and living off the land techniques.
WINWORD.EXE or EXCEL.EXE
→ powershell.exe, cmd.exe or wscript.exe
OUTLOOK.EXE
→ wscript.exe, powershell.exe or mshta.exe
chrome.exe or msedge.exe
→ mshta.exe, powershell.exe or cmd.exe
acrord32.exe
→ rundll32.exe or powershell.exe
w3wp.exe
→ cmd.exe or powershell.exe
sqlservr.exe
→ cmd.exe or powershell.exe
powershell.exe or cmd.exe
→ schtasks.exe, sc.exe or reg.exeThese relationships are not automatically malicious. A business application may launch a script, an administrator may use PowerShell and a database administrator may intentionally enable operating system command execution.
The analyst must inspect the complete command line, user, integrity level, file origin, timing and subsequent behavior.
For example, Word launching PowerShell is a warning sign. Word launching PowerShell with an encoded command that downloads a file into Temp and creates a scheduled task is a much stronger sequence.
A suspicious file becomes more significant when another mechanism ensures that it will execute again.
Run and RunOnce registry keys under HKCU and HKLM are common autostart locations. They are also used by legitimate software. The important part is the referenced file and the context of the registry modification.
A new Run key pointing to a known application in an expected directory may be normal. A new Run key pointing to an unknown executable in Temp, Downloads, Public or a randomly named AppData directory requires investigation.
Scheduled tasks are used by Windows and legitimate applications for maintenance, updates and backups. Suspicion increases when the task uses a misleading Microsoft style name, runs every few minutes or launches PowerShell, a living off the land binary or a payload from a user writable location.
Windows services provide another important persistence and execution mechanism. A newly created service whose ImagePath points to Temp, a user profile, a network share or an unknown executable should be correlated with the account and process that created it.
WMI event subscriptions, Winlogon modifications, Startup folders and drivers can also provide persistence. The analyst does not need to check every possible mechanism for every harmless file. The depth of the investigation should follow the risk of the observed behavior.
Some Windows artifacts are more closely associated with digital forensics, but they can help validate a threat hunting finding when endpoint telemetry is incomplete.
Prefetch may help establish that a program executed and may provide information related to previous executions. It is not enabled in every environment and should not be treated as a complete record of all execution.
Amcache can contain information about applications that were present on the system and may support execution analysis. Its interpretation requires care because presence in an artifact does not always prove execution in the exact way an analyst may initially assume.
C:\$Recycle.Bin may contain deleted tools, payloads or archives. A deleted file may still provide useful metadata or recoverable content.
C:\Windows\System32\winevt\Logs contains Windows Event Log files. Log clearing, logging interruptions or manipulation of these files can be important defense evasion signals.
C:\Windows\System32\config contains critical registry hives such as SAM, SYSTEM, SECURITY and SOFTWARE. Attempts to copy or access these files may be associated with credential access, backup activity or legitimate administrative work. The initiating process and user context determine the risk.
On a Domain Controller, C:\Windows\NTDS\NTDS.dit contains the Active Directory database. Access, copying or shadow copy activity involving NTDS.dit should receive immediate attention because it may expose domain credential material.
When a suspicious file or process is identified, begin by recording the hostname, username, timestamp, process identifier and complete file path. Preserve the original values before moving deeper into the investigation.
Inspect the file name, extension, size, creation time, modification time and SHA 256 hash. Timestamps can provide useful context, but they may be modified and should not be treated as independent proof.
Check the digital signature, certificate and publisher. Confirm that the signer matches the product represented by the path and file name. A valid signature supports legitimacy, but it does not override suspicious behavior.
Review the parent and grandparent processes. Determine which process created or launched the file and whether that relationship is normal for the application.
Inspect the complete command line and integrity level. Look for encoded content, hidden execution, unusual DLL references, external addresses, temporary paths and attempts to disable security controls.
Determine how the file arrived. Was it downloaded by a browser, extracted from an archive, delivered by email, copied from a network share, introduced through removable media or created by another process?
Check prevalence across the environment. A file present on hundreds of systems as part of an approved application has a different context from a file observed for the first time on one endpoint.
Review DNS queries, network connections, destination domains, IP addresses, ports and transferred data. Identify the process responsible for the communication whenever the available telemetry allows it.
Search for persistence involving the file. Review registry Run keys, Startup folders, scheduled tasks, services, WMI activity, Winlogon values and drivers according to the risk of the finding.
Finally, build a timeline around the execution. Determine what happened before the file appeared, what launched it, what it created and what followed.
Technical indicators need operational context.
A signed update component executing from Temp may look unusual but correspond to an approved software update. A remote administration tool may be expected on an IT support workstation. A scheduled task may belong to a backup product.
Before escalation, compare the activity with software deployment records, maintenance windows, change requests, administrator activity and the normal role of the endpoint.
This is not an excuse to close suspicious activity simply because an administrator was involved. Administrator accounts are valuable targets, and legitimate tools are frequently abused. The business explanation must match the technical evidence.
If the change request mentions a software update, but the observed process launches an encoded PowerShell command and contacts an unrelated external domain, the ticket does not explain the complete activity.
A core Windows process executing from a user writable directory should receive high priority.
An unknown executable running from Temp becomes more significant when it is unsigned, launched by Office or a browser, connected to an external destination or followed by persistence.
A new service or scheduled task becomes more significant when it launches a payload from AppData, Public, Downloads, Temp or a network share.
Attempts to access SAM, SECURITY, SYSTEM or NTDS.dit require immediate contextual investigation because they may be associated with credential theft.
A newly installed or vulnerable driver becomes high priority when it is followed by attempts to disable an EDR, antivirus product or another security control.
A file that executes, creates persistence, communicates externally and deletes itself presents a much stronger case than a file that is merely rare or unsigned.
A practical path based hunt can search for core Windows process names running outside their expected directories.
The following is generic search logic and must be adapted to the field names and normalization used by the actual SIEM or EDR platform:
process_name IN (
"svchost.exe",
"lsass.exe",
"services.exe",
"winlogon.exe",
"csrss.exe",
"smss.exe"
)
AND process_path NOT STARTS WITH "C:\Windows\System32\"The query produces candidates for investigation. It does not confirm compromise.
The analyst must also consider operating system architecture, path redirection, Windows version, process implementation details and data quality. Some legitimate components may exist in additional Windows directories, and incomplete path normalization can produce misleading results.
A second hunt can focus on executable or script content launched from temporary and user writable directories:
process_path CONTAINS ANY (
"\AppData\Local\Temp\",
"\Windows\Temp\",
"\Downloads\",
"\Users\Public\"
)
AND file_extension IN (
".exe",
".dll",
".ps1",
".bat",
".cmd",
".vbs",
".js",
".hta"
)This query should be enriched with the parent process, publisher, signature status, prevalence and network activity. Without that context, legitimate installers and update components may generate a large number of results.
A broad hunting query should not automatically become a production alert.
First, identify which combinations created meaningful findings. A file executing from AppData may be common. A file with a Windows system name executing from a random AppData directory, launched by Word and connecting to a new domain is far more specific.
A useful detection can combine several conditions instead of alerting on the path alone. These may include a user writable location, a suspicious parent process, an unsigned or low prevalence file, a system process name, external communication and persistence within a defined time period.
Test the logic against historical data. Review which legitimate applications appear and build narrow, contextual exceptions based on the expected publisher, path, application, endpoint group and process relationship.
Do not globally exclude an entire directory such as AppData or every process signed by a known publisher. Broad exceptions remove the context that makes the detection useful.
The Windows file system gives an analyst a map, but the map does not make the decision.
System32 is expected for many core Windows processes, but a file is not safe only because it is stored there. AppData and Temp are writable locations frequently used by attackers, but legitimate applications also use them every day.
The strongest findings come from contradictions.
A system process name appears in a user directory. A document launches a command interpreter. An updater contacts a destination unrelated to its publisher. A signed application loads an unknown DLL. A temporary executable creates permanent persistence.
Those contradictions are where the investigation becomes valuable.
Learn normal to detect abnormal. Then correlate the abnormal with enough technical and business context to understand what actually happened.
Threat hunting is often incorrectly presented as searching a SIEM for known indicators of compromise or processes such as PowerShell, rundll32.exe and certutil.exe. This type of search can be useful, but it does not represent a complete threat hunt.
Threat hunting is the proactive and structured investigation of activity that may not have generated a security alert but could represent a deviation from the expected behavior of a user, device, account or service. The objective is not to prove that every anomaly is malicious. The objective is to collect enough technical and business context to confirm or reject the initial hypothesis.
Organizations use different combinations of SIEM, EDR, NDR, identity and network security products. One organization may use Microsoft Sentinel and Microsoft Defender, while another uses Splunk and CrowdStrike. Others may use Stellar Cyber, Cybereason, Elastic, QRadar, Fortinet, Palo Alto Networks or several solutions together. Table names, field names and user interfaces may differ, but the analytical logic remains the same.
A SIEM provides correlation and visibility across multiple data sources. An EDR provides process, file, network and device timeline information. Identity platforms provide authentication, session, privilege and administrative activity. DNS, proxy, firewall and NDR telemetry provide information about network communication. The security product may change, but the questions asked by the analyst should remain consistent.
Security alert analysis begins with an alert generated by an existing detection. Threat hunting begins with a hypothesis about activity that may not be covered by current detections or may be hiding within legitimate behavior.
Incident response begins when there is sufficient reason to suspect a compromise or when an incident has already been confirmed. Threat hunting may identify an incident, but not every hunt needs to end with one.
Threat intelligence provides information about threats, tactics, techniques, infrastructure and indicators of compromise. Threat hunters can use this information to develop hypotheses, but an investigation should not be limited to known IP addresses, domains and file hashes.
Threat hunting is also not random log review. A useful hunt has a defined hypothesis, data sources, time range, scope, analytical process, decision criteria and documented result.
A successful hunt does not need to identify an attacker. The result may confirm that the observed behavior is expected, show that an existing detection requires tuning, reveal a telemetry gap or create an opportunity for a new correlation rule.
A hunt may also identify a confirmed compromise that requires incident response. It is equally important to document situations in which the hypothesis cannot be confirmed or rejected because the required telemetry is unavailable. Absence of evidence is not evidence that an activity did not occur.
Before starting a hunt, determine what data the organization actually collects. Do not assume that a specific type of telemetry exists simply because the organization has a SIEM or EDR platform.
First, identify where process creation events are stored and whether they contain the complete command line. Verify whether the data includes the parent process, the user who launched the process, the file path, digital signature, file hash and network connections associated with the process.
Determine where Windows authentication events, Domain Controller logs, Microsoft Entra sign ins, Microsoft 365 audit activities, VPN authentication events, DNS queries, proxy traffic, firewall connections and email telemetry are available.
Check the retention period. A hunt designed to identify a process first observed during the previous thirty days cannot produce reliable results if only seven days of data are retained.
Verify that logs are parsed correctly. The raw event may exist in the SIEM, while important values such as the username, source IP address, destination device or command line may not be extracted into searchable fields.
Review endpoint coverage. If the EDR platform protects workstations but does not cover every server, the absence of endpoint events from a server must not be interpreted as evidence that no activity occurred.
Finally, document all known limitations. Missing PowerShell Script Block Logging, DNS logs, identity events or process level network telemetry must be included in the final assessment.
A hypothesis must be specific, testable and connected to adversary behavior. A statement such as “search for PowerShell attacks” is too broad because it does not define the activity of interest or the conditions that would make a result significant.
A better hypothesis is: “An adversary may use PowerShell launched by a Microsoft Office application to download or execute content from an external destination.”
This hypothesis immediately identifies several requirements. The analyst needs process telemetry, parent and child relationships, command line arguments, user and device context, and network events. PowerShell alone is not enough. The relationship between the parent process, execution method and subsequent behavior is what makes the activity relevant.
Another hypothesis could be: “A compromised administrative account may access administrative shares across multiple devices and subsequently create remote services for lateral movement.”
This hunt requires authentication events, SMB telemetry, share access, service creation events, endpoint processes and context about the administrative account.
After defining the hypothesis, describe the evidence the activity could leave behind. An adversary’s intention is not directly visible in logs. Only the events produced while the action is performed are visible.
Potential PowerShell abuse may create a sequence containing powershell.exe or pwsh.exe, an unusual parent process, an encoded command, a hidden window, a download instruction, communication with a new domain, creation of a file and execution of an additional process.
Pass the Hash activity usually cannot be confirmed with one event. The analyst should search for a combination of network logons, NTLM authentication, an unusual source device, use of a privileged account, access to administrative resources and subsequent remote execution.
This step prevents the hunt from relying on a single Event ID that is expected to prove an entire attack. Most attacks become visible through a sequence of related behaviors rather than one isolated event.
The initial query is used for discovery. Adding restrictive conditions too early can remove relevant activity before the analyst has an opportunity to review it.
For a hunt focused on Microsoft Office applications launching interpreters, the initial logic may look like this:
parent_process IN (
winword.exe,
excel.exe,
powerpnt.exe,
outlook.exe
)
AND
child_process IN (
powershell.exe,
pwsh.exe,
cmd.exe,
wscript.exe,
cscript.exe,
mshta.exe,
rundll32.exe,
regsvr32.exe
)This is not a final detection, and every result is not an incident. The query only identifies events that require additional context.
Group the results by device, user, parent process, child process, command line, hash and time. Determine how frequently each combination occurs and how many devices are involved.
Prioritize combinations that are new, rare, executed from unusual locations or associated with previously unseen network destinations.
A query returns a set of events. Threat hunting begins when the analyst pivots from those events to related entities and develops a broader understanding of the activity.
When a suspicious process is identified, pivot to the device timeline. Continue to the user, parent process, file hash, file path, network destination and child processes.
When suspicious authentication is identified, investigate the same account, source IP address, device, application, destination systems and additional sign ins during the same period.
When a rare domain is identified, determine which devices contacted it, which process generated the traffic, when the domain was first observed, how prevalent it is and whether a file was opened or downloaded before the connection.
Every pivot should answer a specific question. Do not review data without a purpose. When reviewing a process tree, the question may be: “Was this process launched by an expected application or by a document, browser, script interpreter or another unusual parent?”
An alert or query result is almost never the complete story. Review the activity that occurred before and after the selected event.
Begin several minutes before the initial event and expand the time range when additional evidence is discovered. Search for user authentication, document execution, file downloads, DNS queries, network connections, process creation, registry changes, scheduled tasks, services, account creation and attempts to disable security controls.
A useful timeline may show that a user opened a document, winword.exe launched PowerShell, PowerShell contacted a new domain, a file was created in the user’s temporary directory, the file was executed and periodic outbound communication followed.
Each individual event may have a legitimate explanation. Their relationship and sequence can reveal a completely different situation.
Threat hunting is not limited to known indicators of compromise. Much of its value comes from understanding normal activity within the organization.
Determine whether the process is normal for the device and its business role. A process that is expected on an administrative server may be unusual on a finance employee’s workstation.
Check whether the user has performed similar actions before. An administrator may legitimately use remote administration tools, while the same behavior under a standard user account may require further investigation.
Review the prevalence of the file, hash, domain and parent child process combination. Rarity increases the value of a finding, but it does not prove compromise.
Consider the time of the activity. Activity outside normal business hours may be suspicious, but on call work, maintenance and automated tasks may provide a legitimate explanation.
A baseline should not be limited to the entire organization. Baselines are more useful when they consider the user’s role, device type, network segment, application and business process.
A process name is not sufficient for a decision. PowerShell, rundll32.exe, certutil.exe, PsExec, AnyDesk and similar tools may have legitimate administrative purposes.
For every result, determine who initiated the activity, on which device, with which privileges, from which path and as part of which business process.
Analyze the complete command line. A legitimate and malicious process may have the same name but completely different arguments. Look for encoded or obfuscated content, hidden windows, download instructions, unusual DLL files, user writable directories and external network destinations.
Review parent and child processes. Microsoft Word launching PowerShell is a red flag, but it is not proof of compromise. Determine which document was opened, where it originated, what PowerShell executed and what happened next.
Review the digital signature and file hash, but do not use them as the only criteria. A signed binary may be abused or used for legitimate binary proxy execution. A file without an established reputation is also not automatically malicious.
Examine network connections and destination reputation. A new domain is not necessarily malicious, and a well known cloud service is not necessarily safe. Adversaries can use legitimate services for payload hosting, command and control or data exfiltration.
Finally, confirm the business context. Is there an approved change, deployment, administrative task or change management ticket? Does the activity match the person, device, time and purpose described in the business justification?
An allowlist should not be based only on a process or application name. If powershell.exe is globally excluded because administrators use it, an adversary can take advantage of the same exception.
A useful exception combines the approved tool, expected user, appropriate device, known path, digital signer, permitted command line arguments, network destination and time context.
A remote access tool may be permitted on IT support devices when it runs from the official installation directory and connects to known vendor infrastructure. The same tool launched from a temporary user directory on a workstation where it has never been seen should not be automatically excluded.
The hypothesis is: “An adversary may deliver a malicious document that launches PowerShell to download, decode or execute additional content.”
This hunt requires endpoint process events, parent and child relationships, complete command lines, user, file path, hash, network events and, when available, email or web telemetry that can identify the origin of the document.
Begin by searching the SIEM or EDR for events where winword.exe, excel.exe, powerpnt.exe or outlook.exe launched powershell.exe or pwsh.exe.
Record the time, user, device, parent command line, PowerShell command line, document path and all available file hashes.
Check whether the command contains EncodedCommand, FromBase64String, Invoke Expression, DownloadString, Invoke WebRequest, hidden window options, bypass parameters, an external address or a path pointing to Temp, Downloads, AppData or Public.
If the content is encoded, decode it in a safe analytical environment. Do not execute it. The objective is to identify the actual command, network destination, file path and intended action.
Open the process tree and determine what occurred before the Microsoft Office process. Identify the document name, location and opening time. If email telemetry is available, review the sender, subject, attachment, URLs and other recipients of the message.
Review every child process started by PowerShell. Search for additional interpreters, LOLBins, archive utilities, credential access tools, security configuration changes and execution of newly created files.
Review network events. Determine whether PowerShell or a child process contacted an external IP address or domain. Check whether the destination was previously observed, how many devices accessed it, its reputation and whether a new file was created after the connection.
Expand the investigation across the environment using the same hash, domain, URL and file name. This establishes whether the finding is isolated or part of a broader phishing or malware campaign.
A legitimate explanation may involve an approved business document, macro or add in. Confirmation should include a known document, expected user, documented business process, approved script, appropriate signature and behavior that is not associated with suspicious downloading or execution.
If a Microsoft Office application launches PowerShell with an encoded command, downloads a file from a new domain and executes unsigned content from a temporary directory, there are multiple correlated indicators supporting incident escalation.
Expected behavior means the activity has been confirmed as a normal part of an approved business or technical process and does not violate security policy.
A Benign True Positive means the detection correctly identified the behavior it was designed to detect, but the activity had a legitimate and confirmed explanation. An administrator using a dual use command during approved maintenance is one possible example.
A Malicious True Positive means there is evidence of malicious or unauthorized activity. At this point, the hunt transitions into incident response and the full scope of the compromise must be established.
A False Positive means the query or detection logic incorrectly interpreted the event, field or data combination. This result usually requires a change to the query, parser or detection logic.
Inconclusive means that the available data or business context is insufficient for a reliable decision. The missing data and recommended visibility improvements should be clearly documented.
One suspicious signal is rarely sufficient. The decision should be based on correlated behavior.
Increase the priority when the activity combines an unexpected user, a process observed for the first time, execution from a user writable directory, an encoded command, a suspicious parent process, a new external destination, credential access, lateral movement, persistence, privilege escalation, security control modification or evidence removal.
When active compromise is identified, transition to the incident response process. Depending on the situation, actions may include device isolation, indicator blocking, session revocation, account disablement, credential reset, forensic collection and investigation of related systems.
An analyst should not wait for perfect evidence when there is a credible risk of continued compromise. At the same time, the response must remain proportional to the available evidence and potential business impact.
When a hunt identifies a useful and repeatable pattern, determine whether it can become a detection.
Do not simply copy the initial query and enable an alert for every result. The initial query is intentionally broad and would likely create excessive alert volume.
Identify the elements that separated risky activity from legitimate behavior. These may include an unusual parent process, specific command line arguments, a user writable path, low prevalence, a new network destination or a sequence of events within a defined time window.
Define the required data sources, correlation period, threshold, asset context and precise exceptions. Test the detection against historical data before enabling it in production.
After deployment, monitor the number of alerts, available context, Benign True Positive results and activities that the logic fails to identify. A detection is not a finished product. It must evolve with the organization’s infrastructure and behavior.
Record the hunt name, date, analyst, hypothesis, MITRE ATT&CK mapping, time range, scope, data sources and query versions.
Document the users, devices, IP addresses, processes, hashes, domains and other relevant entities. Add a timeline and explain how the events are connected.
Record which legitimate explanations were considered, which data was unavailable, how the result was classified and why the decision was made.
Define the next actions, owner and deadline. If the hunt identifies a need for a new detection, tuning, additional logging or a security control change, include it in the final result.
A SOC team can perform one narrowly defined hunt each week based on current risks, infrastructure changes or new threat intelligence.
A monthly review should evaluate previous hunt results, recurring anomalies, telemetry gaps and queries that could become detections.
After a confirmed incident, perform a retrospective hunt across the entire available retention period and all relevant data sources. The objective is to identify the initial activity, additional affected systems and earlier events that existing detections did not identify.
After onboarding a new client, system or data source, establish baselines for authentication, administrative behavior, remote access tools, privileged accounts, processes, domains and network communication.
Threat hunting is not a search for security alerts. An alert applies predefined detection logic to identify a known pattern. A threat hunt begins with a question about activity that may not yet have an appropriate detection.
The most important skill is not memorizing the syntax of one SIEM or EDR platform. It is the ability to translate a hypothesis into expected telemetry, locate the relevant events, connect entities, build a timeline and understand the business context.
A query is not the complete threat hunt. A query finds events. Threat hunting begins when the analyst connects behavior, users, devices, processes, network destinations and time, and then uses evidence to determine what actually happened.
Learn normal to detect abnormal. Suspicious behavior is not automatic proof of compromise, but a known tool, signed file or administrative account is not automatic proof of legitimacy. Context and event correlation are what transform security data into a reliable analytical conclusion.
If you're just entering the world of cybersecurity, you'll very quickly come across hundreds of different certifications, recommendations, and opinions. The problem is that a large number of lists on the internet come down to copying the same recommendations year after year. That's why the question of how much a particular certification will actually help you when you first sit down in front of a real system, security tool, or incident is often neglected.
This text was created from the perspective of a person who works in the field of cybersecurity every day. I'm not involved in penetration testing, malware development, or risk management at the management and board level. My area is security operations, network security, system administration, incident analysis, detections, and working with security tools. That's precisely why the certifications on this list were chosen from that point of view.
Cybersecurity is not a single profession. Within it there is network security, system security, identity management, security operations, forensics, cloud security, incident response, and many other areas. There is no single certification that will cover everything. However, there are a few certifications that represent a very solid start for a large number of future professionals.
CCNA is one of the rare entry-level certifications that simultaneously forces you into a theoretical and practical understanding of technology. That's exactly why I consider it one of the most valuable certifications for starting a career in information technology and cybersecurity.
A large number of beginners want to immediately study advanced security topics, but in doing so they skip the network fundamentals. In practice, the network is precisely the place where a large part of security events take place. Analyzing network traffic, working with firewalls, network segmentation, virtual private networks, intrusion detection and prevention systems, and analyzing suspicious communication all require a good understanding of network technologies.
CCNA covers addressing, routing, switching, wireless networks, automation, security fundamentals, and the operation of network infrastructure. A person who properly masters this material often advances much more easily toward security operations, incident analysis, and working with SIEM platforms.
One thing that rarely anyone mentions is that CCNA often develops a way of thinking that you later use in security. When you learn how a network works under normal conditions, it's much easier to recognize when something isn't normal. That's exactly where a large part of security work begins.
The certification is valid for three years and can be renewed through the Cisco Continuing Education program or by retaking the appropriate exam. From my perspective, there are few entry-level certifications that push a candidate so much to truly understand the technology, and not just the definitions. That's exactly why I still consider CCNA to this day one of the highest-quality starting points for people who want to build a career in networks or cybersecurity.
CompTIA Security+ is probably the most well-known entry-level certification in the field of cybersecurity. If you search through job ads in the security field, you'll very often come across this particular certification.
Unlike the CCNA certification, Security+ doesn't go as deep into individual technologies. Its value lies in its breadth. The candidate goes through threats, vulnerabilities, identity management, cryptography, security operations, risk management, and basic security concepts that appear in almost every security environment.
From my own experience, I can say that Security+ is one of the certifications that employers and recruiters most often recognize when it comes to entry-level security certifications. This of course doesn't guarantee a job, but it often helps a résumé get additional attention.
CompTIA also offers an interesting certification ecosystem. By passing more advanced certifications, it's possible to renew certain lower-level certifications within the same program, which can make sense in the long run for people who plan to build a career through the CompTIA certification path.
It's hard today to find an organization that doesn't use Microsoft technologies in some way. That's exactly why SC 900 represents a very useful entry-level certification for anyone who wants to work in the field of cybersecurity.
The material covers Microsoft Entra identities, Microsoft Defender security solutions, Microsoft Purview, concepts of data protection, access management, security operations, and compliance.
It doesn't go deep into individual technologies, but you get a very solid overview of the Microsoft security ecosystem. This is especially important because a large number of organizations use Microsoft Defender products to protect endpoint devices, email, identities, and the cloud.
SC 900 is not a formal prerequisite for SC 200, but it represents an excellent introduction to the Microsoft security world. An additional advantage is that Fundamentals certifications don't expire.
SC 900 is not a certification after which you'll know how to administer Microsoft security solutions. Its value lies in the fact that it provides an overview of the entire ecosystem and helps you understand how identities, data protection, security operations, and compliance are interconnected.
Cloud security is no longer a specialization reserved only for large organizations. Today, almost every company uses at least part of its infrastructure or services hosted in the cloud.
AZ 900 explains the basic concepts of cloud computing, Azure services, network architecture, resource management, security, and the shared responsibility model. These are terms that almost every cybersecurity professional will encounter sooner or later.
Although it's an entry-level certification, AZ 900 often helps you understand topics that will later be important when working with security tools, identities, access policies, and data protection in a Microsoft environment.
Beginners often underestimate the cloud because they don't see it every day like the computer on their desk or the network device in the communication cabinet. However, a large part of modern systems today is located precisely in the cloud, which is why understanding the basic Azure concepts is becoming increasingly important even for people who don't plan to work in cloud administration.
SSCP is a certification that often stands in the shadow of the more well-known CISSP certification. However, for a large number of people, SSCP is precisely the logical step between entry-level certifications and more advanced security certifications.
It's focused on system security, access management, security operations, incident response, network security, and infrastructure protection. In other words, it's closer to the everyday work of system administrators and security operations professionals.
What sets SSCP apart from some other entry-level certifications is its emphasis on the operational side of security. That's exactly why many see it as a good choice for people who work or plan to work at the intersection of system administration and cybersecurity.
Not everyone needs to follow the same certification path. Someone will build their career through Cisco, someone through Microsoft, someone through CompTIA, and someone through ISC2. The most important thing is that the chosen certification supports the direction in which you want to develop your knowledge.
When people first enter the world of cybersecurity, they often look for one perfect certification. Such a certification doesn't exist. There are only different paths of development, depending on the area that interests you.
One of the highest-quality overviews of possible certification paths can be found on Paul Jerimy's Security Certification Roadmap project. That certification path very clearly shows how broad a field cybersecurity is and how many different specializations exist within it.
One of my superiors showed it to me, and since then I've been recommending it to people who are trying to find a direction of development. Although it was created in 2024, most of the certifications shown are still relevant. Some may have changed their name or version, but the logic of career development has remained the same.
You can find the certification path at: https://pauljerimy.com/security-certification-roadmap/
The biggest mistake I see among beginners is searching for the perfect certification. Such a certification doesn't exist. There are only certifications that better or worse suit the area in which you want to develop.
If you ask me, it's much more important to understand why something works than to pass another exam. A certification can open the door to a job interview, but knowledge is what will keep you in that position and help you advance further.
And what is perhaps most important is to use the acquired knowledge for practical purposes. A certification in itself doesn't mean much if what you've learned is never applied to real systems, real problems, and real incidents.
This is of course my personal opinion based on experience. People who do penetration testing or risk management would probably put together a different list. And that's precisely one of the more interesting things in cybersecurity. There are many different paths, and not just one correct one.
One of the most common mistakes among SOC analysts is believing that the analysis is complete the moment they find an alert. In reality, an alert is not the answer. An alert is only the beginning of an investigation.
Security tools are designed to help analysts understand what is happening or what has happened on a system. They collect, correlate, and highlight events that may be security-relevant and direct attention toward activities that require further investigation. However, on their own, they rarely provide a complete picture of an incident. That is why contextual analysis remains one of the most important responsibilities of every SOC analyst.
This is precisely why two identical alerts can represent completely different situations. One may be a legitimate administrative activity, while the other may be the beginning of a serious compromise.
When an alert appears, the first question should not be how to close it. The first question should be why the rule triggered in the first place. Only when we understand the logic behind the rule can we understand what actually happened on the system.
For example, if we see an "Encoded PowerShell" alert, the mere fact that PowerShell was executed is not enough to draw a conclusion. We need to understand what was executed, who executed it, from which context, and for what purpose.
At that point, the analysis is only beginning.
Step 1 – An Alert Is Received
The first step is to review the alert and gather basic information. This includes checking the rule name, event time, user, device, data source, and severity level.
At this stage, no conclusions should be made. The goal is to understand what the system has detected.
Step 2 – Read the Rule Name
The rule name often provides the first clues about what should be analyzed.
If we see a rule called "Abnormal Parent Child Process," we immediately know that we will need to analyze the relationship between the parent process and the child process.
If we see "Encoded PowerShell," the investigation will focus on PowerShell commands and command-line arguments.
If we see "Impossible Travel," we will analyze user logins, geolocation data, and authentication events.
A good analyst first tries to understand what the rule is attempting to detect.
Step 3 – Read the Rule Description
After reading the rule name, the next step is to review the rule description.
The description explains why the alert was generated, what behavior is considered suspicious, and what the rule is actually designed to detect.
Only after understanding the rule logic can a quality investigation begin.
Step 4 – Determine the Starting Point of the Investigation
Every rule has its own starting point.
If the alert is related to a user account, login activity, multi-factor authentication events, IP addresses, and geolocation data should be analyzed.
If the alert is related to a process, the parent process, child process, command-line arguments, and execution path should be reviewed.
If the alert is related to network activity, IP addresses, domains, network connections, and destination reputation should be examined.
The rule determines where the investigation begins.
Step 5 – Gather Context
A single alert almost never provides the complete picture.
Additional alerts, related incidents, indicators of compromise, process activity, user actions, network communications, and historical events should all be collected and reviewed.
Only then can we begin to understand what actually happened.
Step 6 – Analyze Process Context
Many analysts focus solely on the process name.
That is not enough.
For example, powershell.exe by itself means very little. It is necessary to determine who launched it, when it was launched, which parent process initiated it, what commands were executed, whether network communication occurred, and whether the process is digitally signed.
It is especially important to analyze the relationship between the parent process and the child process. While processes routinely spawn other processes during normal operation, there are situations where that relationship may indicate a system compromise.
For example, if explorer.exe launches cmd.exe or powershell.exe, the behavior may be perfectly legitimate. However, if a Microsoft Office document launches powershell.exe, which then launches additional processes or establishes network communication, further investigation is required to determine whether the activity is legitimate or malicious.
Process context is often more important than the process itself. Analysts must understand why the process was executed, under what circumstances, by which user, and whether the behavior is normal for the environment being analyzed.
Step 7 – Analyze the Process Execution Path
It is very important to determine where a process was launched from.
A process executing from C:\Windows\System32 is very different from a process executing from AppData, Temp, or Downloads directories.
However, this is where one of the most common mistakes in security analysis occurs.
Activity originating from the Temp directory does not automatically indicate an attack.
During software upgrades, installations, patch deployments, and system implementation activities, it is common for files to be temporarily extracted and executed from temporary directories.
In other words, legitimate activity can sometimes look very similar to malicious activity.
Likewise, PowerShell is not malicious by itself. Cmd is not malicious by itself. Rundll32 is not malicious by itself. These are legitimate Windows tools used by both administrators and attackers.
This is why context determines whether an activity is legitimate or malicious.
For that reason, the execution path alone should never be the sole factor used to assess an incident. The entire context must be considered before drawing conclusions.
Step 8 – Verify Whether the Activity Is Legitimate
After completing the technical analysis, it is important to answer a simple question:
Did the user expect this activity?
Very often, the user provides the information needed to confirm or dismiss suspicion.
It may turn out that the activity was part of a software upgrade, an administrative task, a new system deployment, an automated process, or a legitimate business operation.
At first glance, such activities may appear identical to a compromise.
Step 9 – Draw a Conclusion
Only after gathering all relevant information can a conclusion be reached.
Is this legitimate activity? Is it a false positive? Is it suspicious activity? Is it a confirmed compromise?
Skipping investigation steps almost always leads to incorrect conclusions.
Step 10 – Apply the Appropriate Response Procedure
Once we understand what happened, we apply the appropriate response procedure.
This may involve procedures for user accounts, endpoints, malware, persistence mechanisms, lateral movement, or incident response.
A procedure is not intended to limit an analyst. Its purpose is not to encourage blind execution of steps.
A good procedure serves as a guide that ensures every analyst follows the same critical investigative steps. It helps ensure that important information, indicators of compromise, related events, and key findings are not overlooked.
Quality analysis is not a checklist of clicks performed in a SIEM or EDR platform. Quality analysis is the process of asking questions and finding answers through available data.
A good analyst constantly looks for additional context. Are there related alerts? Has the user performed unusual actions? Are there indicators of compromise? Has similar activity been observed on other systems? Is there communication with suspicious IP addresses or domains?
The difference between an operator who processes alerts and an analyst who performs investigations lies in the way they think.
An operator sees an alert and looks for a reason to close it.
An analyst sees an alert and looks for the reason it was triggered.
Every detection rule has a specific purpose and logic. If we do not understand what a rule is trying to detect, there is a high probability that we will miss important indicators of compromise or incorrectly assess the severity of an event.
Only after understanding what happened can we apply the appropriate response procedure.
The purpose of a procedure is to ensure that every analyst follows the same critical analysis steps and does not overlook important information during the investigation.
A good procedure does not tell an analyst what to think.
A good procedure ensures that the analyst asks all the right questions.
The most important skill of a SOC analyst is not knowledge of a specific tool, but the ability to understand context and connect information.
Analysis begins by reading the rule.
It continues through understanding the context.
It ends with conclusions based on evidence.
An alert is not proof of compromise.
An alert is an indicator that something requires further investigation.
Good analysis does not look for a reason to close an alert.
Good analysis looks for the reason why the alert was triggered.
Before we get to the concrete steps I'm going to lay out in this article, we need to ask ourselves a few practical questions: why do I want a job in IT at all, and then in cybersecurity specifically? As with any other job, the first question is: am I here for the right reasons? Getting into IT is not a decision made overnight, and unfortunately, the job doesn't come overnight either.
Many people hear glowing stories about this industry and make their decision based on them. The big salary and the comfortable conditions of working from home are usually the first things mentioned. Swept up by those stories, they make hasty decisions without ever asking themselves whether they will actually enjoy the work.
Some of them pay serious money for a course and realize halfway through that it's not for them. Others push through to the end purely because they've already paid, knowing full well they will never work in the field. Education in this area is painful precisely for the kind of people who fell for the polished marketing stories, and some of them can't even install a program, let alone set up a virtual machine.
It's easy to do a job you don't love when it's slow-paced and undemanding, but a job in IT or cybersecurity is anything but. When you get stuck in a job that is extremely demanding and complex, and you don't love it, it creates a whole chain of problems. The consequences hit not only you, but the people around you as well.
The complexity of this work comes from the fact that technology advances incredibly fast and demands an enormous amount of focus. The work environment is usually fast-paced and full of critical systems that require high availability, with countless important processes and businesses depending on them. On top of that, you handle a huge amount of information and data on which, at times, human lives depend, so any mistake can cause serious problems.
You often come across confessions like: "I fell for an ad for a cybersecurity course and thought I could beat the job market, but I couldn't." They are followed by questions like: is it me or the industry, should I give up, and how am I supposed to gain experience if nobody wants to give me a chance? Reading stories like these, I conclude that the people writing them are exactly the ones who didn't get into this field for the right reasons.
If you are here for the right reasons, what follows is the brutal truth about how to land your first job in IT in general, and in cybersecurity in particular. The principle is exactly the same in both cases. The steps are always the same.
Once you finally decide to head in this direction, it doesn't really matter whether you choose self-study, formal education, or a course. Everyone picks the approach that suits them best. The most important thing is to stay true to yourself.
My recommendation, though, is to enroll in university, primarily because of the traditional approach and structure. Courses are fast, often cover only general topics, and last a very short time, so they're great for scratching the surface. University isn't necessarily better, but it offers a structure that courses simply don't have.
University does take more time, but in return you gain the virtue of patience, which is absolutely essential in this line of work. There's also the free dopamine of passing exams and solving assignments, almost like completing quests in a video game. The heavy dose of mathematics is also extremely important because it trains your brain to think analytically, and traditional education ultimately offers a broader, more general foundation.
But here's the key thing: if you don't plan to study on your own in your free time on top of all that, the whole effort is pointless. In that case, you're better off not pursuing this career at all. Self-study is not an option, it's the foundation.
Google is still your best friend, even in the age of artificial intelligence. Ask yourself: am I resourceful, do I enjoy searching and digging for answers? If you don't mind when a simple troubleshooting task turns into hours of exhaustive digging through documentation, forums, and logs, feel free to keep reading.
There are various virtual events where you can get vouchers for certifications, and many of them are completely free. It just takes a bit of research. Which brings us right back to resourcefulness as a core trait.
Think about your habits at home as well: do you fix technical problems yourself, do you run a virtual machine or two? How many times have you installed an operating system on your own, and how many times have you broken your own computer while experimenting? If you recognize yourself in this, there's a good chance you will genuinely love this industry.
There are plenty of platforms offering quality CV templates, so there's no need to reinvent the wheel. Your CV must fit on a single page, have a white background, and look tidy, not like a circus. The format should be PDF, and my recommendation is to leave your photo out of it, something you can research further on your own.
Conciseness, brevity, and simplicity are the rule. Use a formal, neutral font, state your full name, a short description in a few lines, and your completed education. Anything that doesn't serve the goal, cut it out.
In my own CV, I don't list all the jobs I've had before, because they simply aren't relevant to this industry. At interviews, that left the impression of a gap in my career and, predictably, raised questions. But when I was asked about it, I didn't take it negatively; instead, I used the question to deliver a great answer.
People fear questions like that, yet psychologically, they can be turned to your advantage. An example answer: I decided to switch to this industry and didn't list jobs that aren't relevant to it, and besides, it bothered me that my CV spilled onto a second page, which wasn't aesthetically pleasing. And why is there a gap? Because I decided on a career pivot and was brave enough to head in the direction that has genuinely interested me my whole life.
After the CV, the cover letter is extremely important as well. When you're looking for your first job, your letter must be bold and direct. There's no room for lukewarm, generic phrases that an employer reads a hundred times a day.
I usually opened my letters with the sentence: "I don't know anything yet, but I'm interested in this and that, and in my free time I study the following." Everything else you write must, above all, be grounded in honesty. Always stay true to yourself, because doors are always open to individuals who embrace their uniqueness.
Let's be realistic: your first job will most likely mean working for a modest salary, or as we'd say, peanuts. Be patient and accept it, because it's your ticket into the industry. Don't think too much about the number at the beginning; instead, work hard and rack up hours of real practice.
Be prepared to be thrown into the fire from day one. Take on every challenge that comes your way until you become confident in yourself and your knowledge. That is the only way forward.
Cybersecurity is a field where you need to know a lot, so setting priorities wisely is crucial. My advice is to focus on networking fundamentals, because without them you simply can't move forward. By that I mean understanding the OSI and TCP/IP models, the difference between TCP and UDP, and how a packet actually travels from point A to point B.
Learn the essential ports and protocols by heart: 80 and 443 for HTTP and HTTPS, 22 for SSH, 53 for DNS, 25 for SMTP, 3389 for RDP, 445 for SMB. Along with that come HTTP status codes, because the difference between 200, 301, 403, 404, and 500 tells you a lot about what's happening on the web. Add to that a basic understanding of network devices: what a switch does, what a router does, and what a firewall does.
The next priority is operating systems and basic knowledge of processes, primarily Windows processes, since most business environments run on the Windows platform. Because people themselves are the biggest security risk, and they predominantly use Windows, it's important to know the processes that can easily be abused to compromise a system. You need to be able to recognize legitimate system processes like svchost.exe, lsass.exe, or explorer.exe, and understand why it's suspicious when such a process runs from the wrong path or with an unusual parent process.
That brings us to the process chain: who spawned whom, in what order, and with what arguments. When you see Word spawning PowerShell, and PowerShell downloading something from the internet, that's a story you must be able to tell at an interview. Learn where and how to find that information, for example in Windows event logs, because that is every analyst's daily bread.
Furthermore, you need to understand what hashes are and why they're useful to us. Algorithms like MD5, SHA-1, and SHA-256 are used for verifying file integrity, identifying malicious code, and storing passwords. When you can explain at an interview why the same malicious sample can always be recognized by its hash, and why MD5 is no longer a safe choice, you're already ahead of most candidates.
Then there's OSINT, the gathering of information from publicly available sources. It covers everything from advanced searches and public registries to tools for checking the reputation of domains, IP addresses, and files. The resourcefulness I wrote about earlier comes into full play here.
And finally, Linux: let this operating system be your daily prayer, because most security devices and systems run precisely on Linux or on Linux-based systems. Learn to navigate the terminal, read logs from the /var/log directory, handle commands like grep, cat, ps, and netstat, and understand file permissions. Operating systems are, I repeat, the foundation of everything, and above all of it stands one rule: be consistent.
If you'd like to know which CV template I recommend or which education I think is worth it, feel free to send me a message. I'll gladly share concrete recommendations from my own experience, and take a look at the links where I also offer my own courses. Good luck, and see you in the industry!
When people think of a home firewall, many still imagine a device that simply allows or blocks traffic between a local network and the internet. However, modern solutions have evolved far beyond that role.
Today's firewalls can analyze application traffic, perform SSL/TLS inspection, leverage threat intelligence sources, identify known attack patterns, and make security decisions based on far more than just IP addresses and ports.
As a result, technologies that were once reserved for enterprise environments are now available to anyone looking for greater visibility and control over their network, whether for learning, testing new technologies, or building a home lab.
For this comparison, I focused on three solutions that are frequently mentioned among network administrators and enthusiasts: Sophos Firewall Home Edition, OPNsense, and pfSense.
While all three products can easily handle core functions such as routing, NAT, VPN connectivity, and network segmentation, the differences become apparent when evaluating security capabilities, integrations, administration, and overall design philosophy.
Sophos Firewall Home Edition is built on the same platform used in enterprise environments. As a result, users gain access to a wide range of capabilities typically found in significantly more expensive commercial solutions.
In addition to standard traffic filtering rules, it includes IPS, web filtering, application control, SSL/TLS inspection, geo-IP filtering, protection against various network attacks, and advanced threat detection capabilities.
One particularly interesting feature is Extended Threat Feeds. Through API integrations, administrators can automatically import IOCs such as malicious IP addresses, domains, and URLs from external sources. This allows the firewall to consume data from threat intelligence platforms, custom IOC feeds, or other security systems and automatically make decisions about blocking or flagging traffic.
For users interested in automation, integrations, and modern defensive strategies, this is a highly valuable capability that is rarely seen in free home editions.
What stands out most to me is how much functionality is integrated directly into the platform. There is no need to install multiple add-ons or combine several separate components to achieve advanced security functionality.
Deployment is relatively straightforward, the administrative interface is easy to navigate, and a large number of features are available immediately after installation. Because of this, Sophos feels like a very complete solution that successfully combines ease of use with advanced security capabilities.
OPNsense represents a different philosophy.
As an open-source project, it offers users a very high level of flexibility and control. Rather than following a predefined approach, administrators decide which components they want to use and how they want to implement them.
One of OPNsense's greatest strengths is its extensive ecosystem of plugins. Tools such as Suricata, WireGuard, Zenarmor, HAProxy, and many others can be integrated into an existing environment with relative ease.
This approach enables the creation of highly customized and powerful environments tailored to specific requirements. At the same time, it requires additional time for configuration, maintenance, and understanding the various components involved.
For administrators who prefer complete control over every aspect of their infrastructure, this is often OPNsense's biggest advantage.
pfSense has long been one of the most recognizable names in the home and small business firewall space.
Its greatest strengths are platform maturity, a large user community, and extensive documentation. Almost any issue you encounter has likely been documented or solved by someone before.
From a functionality standpoint, pfSense remains a highly capable solution that can satisfy the needs of most users. It is stable, proven, and well known throughout the networking community.
That said, in recent years part of the community has gradually shifted toward OPNsense, primarily due to its more open development model and faster adoption of certain features.
When comparing security products, one question inevitably comes up: which one is the most secure?
In reality, the answer is not that simple.
Sophos has experienced several serious vulnerabilities that allowed remote code execution and other forms of system compromise. Due to its significant presence in enterprise environments, such issues often receive considerable attention from the security community.
On the other hand, both OPNsense and pfSense regularly release security updates addressing newly discovered vulnerabilities. The mere existence of CVEs says very little about the quality of a product. What matters far more is how quickly vendors respond, how transparently they communicate issues, and how easily users can apply available patches.
Another concept worth discussing is technological diversity.
When designing security architecture, the goal is not always to find a single solution capable of doing everything. Depending on requirements and available resources, there can be value in using multiple security technologies.
The reason is not only functionality but also risk reduction. If an entire infrastructure relies on a single vendor, a critical vulnerability may have a much greater impact than in an environment built on multiple technologies.
Different vendors use different development teams, security controls, and defensive approaches. A vulnerability affecting one product will not necessarily exist in another.
From an attacker's perspective, homogeneous environments are often more predictable. More diverse environments typically require additional research, adaptation, and resources to compromise successfully.
Of course, introducing additional technologies also increases operational complexity, so finding the right balance between security and manageability remains important.
All three products have their place and their audience.
OPNsense will likely appeal most to users seeking maximum flexibility and openness. pfSense remains a stable and proven platform backed by a large community and extensive documentation.
In this comparison, Sophos Firewall Home Edition stood out the most to me. The amount of functionality available immediately after deployment, ease of implementation, integrated security capabilities, and the ability to leverage threat intelligence data without additional tools left a very positive impression.
Of course, this is far from the final list of technologies I plan to explore.
One of the reasons I maintain a home lab is the opportunity to test different technologies, compare approaches from different vendors, and gain hands-on experience outside production environments.
That brings me to a question for the wider community.
What solution should I implement next in my home lab? Are there any firewalls, IDS/IPS platforms, networking tools, or security products that you believe deserve more attention than they currently receive?
Feel free to leave your suggestions in the comments. One of them might become the subject of a future technical review.
In cybersecurity, the focus is almost always on technology. Organizations invest significant resources into defensive systems, advanced firewalls, EDR platforms, threat detection systems, network segmentation, and multi factor authentication. Security assessments are performed, patches are regularly applied, and strict security policies are defined.
Despite all of this, sometimes a single click is enough.
One link. One fake login page. One attachment opened at the wrong moment.
In that moment, months of security work and significant financial investments in protection systems can be undone.
This does not mean that security technologies are ineffective. On the contrary. Their proper implementation is the foundation of any serious security strategy. The issue is that most security solutions protect infrastructure, while attackers very often target the people who operate and use that infrastructure.
Attackers use different methods to reach their objective. Sometimes they exploit technical vulnerabilities, sometimes misconfigurations, and sometimes they attempt to deceive the user.
Social engineering is a separate approach that relies on manipulating human decisions rather than exploiting technical weaknesses in systems.
In an environment where technical defenses are becoming stronger, attention is increasingly shifting toward the human element.
Why invest time in breaking into systems when it is possible to trick a user into approving access or voluntarily providing credentials.
For this reason, the human factor becomes a key entry point for attackers.
It is often assumed that users are careless or insufficiently trained. This explanation oversimplifies the real problem.
Most employees do not come to work with the intention of harming the organization. Their primary focus is performing their assigned tasks.
Accountants process invoices. Sales representatives communicate with clients. Project managers manage projects. None of them are hired to analyze technical email headers or verify sender domains.
Security teams often forget that security is their primary responsibility, but not the responsibility of most employees.
When a person receives a message that appears to come from a manager, supplier, or colleague, the decision is made within seconds. A large portion of successful attacks relies on this speed of decision making.
After an incident, the same sentence often remains.
But I thought I was talking to the CEO.
Many organizations can present records of completed security training. Employees attended presentations, confirmed participation, and completed mandatory tests.
The real question remains the same. Are they actually more capable of recognizing an attack afterwards.
The quality of training is not measured by the number of sessions delivered, but by changes in behavior in real situations.
A particular issue arises with phishing simulations. Instead of serving as a realistic assessment, they often become a tool to demonstrate that no real problem exists.
If the results are poor, explanations are sought. If click rates are high, the simulation is declared unrealistic. In some cases, campaigns are stopped early to make the results appear more acceptable.
Such an approach does not improve security. It only creates an illusion of control.
An organization that does not accept its real state does not solve the problem. It only delays the moment when an actual attacker will expose it.
One of the most common misconceptions in the industry is the belief that it is possible to build a system that cannot be compromised.
Such a system does not exist.
Every technology has limitations. Every process has exceptions. Every human can make mistakes.
Organizational maturity is not measured by whether incidents can be fully prevented, but by how quickly they are detected and how effectively they are handled.
This is precisely why security tools provide real value.
EDR is not implemented to make systems unbreachable. SIEM is not introduced to eliminate all threats. Multi factor authentication is not a guarantee of complete protection.
There is no universal solution in cybersecurity.
These systems exist to provide better visibility, higher quality data, and stronger response capabilities when incidents occur.
Security is not a state. Security is a process.
The most advanced security system will not independently analyze the context of an incident. It will not understand business impact. It will not make decisions.
Technology generates data. People turn that data into decisions.
For this reason, the human factor is both the greatest risk and the most important element of defense.
The same user who can become an entry point for compromise can also be the one who first notices suspicious activity and responds in time.
Cybersecurity is not a fight against users. It is a process in which human behavior is shaped to become part of the defensive mechanism rather than its weakness.
Technology is necessary. Processes are necessary. But at the end of every infrastructure stands a human being.
For this reason, the human factor remains one of the key challenges of modern cybersecurity.
I recently came across a program that gives you a 100% discount voucher for Microsoft certification exams, and I think more people should know about it.
👉 https://skillupwithlevelup.com/courses
Personally, I completed three courses and received two vouchers — so my best guess is that the limit is two vouchers per person. Choose your courses wisely.
This is a legitimate opportunity to get certified without spending money, as long as you're prepared and move quickly.
Have you tried this already? Drop a comment — would love to hear which certifications people are going for.
📌 Always check the prerequisites. All expert-level certifications require at least one associate-level certification before you can earn them. For example, to achieve the SC-100 (Cybersecurity Architect Expert), you must first hold SC-200, SC-300, or AZ-500. Make sure you double-check the requirements for your target certification before you enroll in the course.
Wazuh is an open-source SIEM and XDR platform that provides centralized collection, analysis, and correlation of security events from endpoints, network devices, and cloud services. Thanks to its modular architecture and combined agent-based and agentless approach, it is ideal for home labs, education, and smaller production environments.
Setting up a home SIEM is an excellent way to understand real security processes: log collection, event correlation, anomaly detection, and incident response. This guide walks through the entire process — from preparing the virtual machine to ingesting logs from endpoints and firewalls.
For the Wazuh server, a Linux distribution such as Ubuntu Server or Debian is recommended. A minimal configuration for a home lab includes:
According to Wazuh documentation, resource consumption scales linearly with the number of agents. Each agent generates its own volume of events including authentication logs, system changes, FIM entries, processes, and network activity. This means CPU, RAM, and disk requirements increase depending on the number of endpoints.
A small home lab with a few agents can run on 2–4 GB RAM, while environments with ten or more agents require additional resources to keep indexing and event processing stable.
After creating the VM in VirtualBox, VMware, or Proxmox, install the operating system and assign a static IP address so the Wazuh server is easily reachable by other devices.
Wazuh provides a simple installation script that automatically deploys Elasticsearch, Kibana, and the Wazuh server. This is the fastest and most stable method for home use.
On a fresh OS installation, run:
curl -sO https://packages.wazuh.com/4.7/wazuh-install.sh
sudo bash wazuh-install.sh -a
The installation takes a few minutes.
Once complete, the Wazuh dashboard is available in your browser, typically at:
https://IP-address:5601
Log in using the initial credentials generated by the installation script.
Wazuh agents collect logs from Windows, Linux, and macOS systems. On Windows, the agent is installed via an MSI installer, while Linux systems use the package manager.
In the Wazuh dashboard, open: Agents → Deploy new agent
Choose the operating system and follow the instructions.
Key parameters include:
Once installed, the agent registers automatically and begins sending logs including system events, authentications, file changes, processes, and network activity.
Wazuh can receive Syslog events from any firewall capable of sending logs to a remote Syslog server. Since Wazuh includes a built-in Syslog listener, the firewall can send logs directly to Wazuh without requiring an intermediate server.
When the firewall sends events, Wazuh stores them in:
/var/ossec/logs/archives/archives.log
The logs are stored in raw form under agent ID 000 because this is an agentless source.
If logs do not appear, enable log archiving in:
ossec.conf
<global>
<alerts_log>yes</alerts_log>
<logall>yes</logall>
<logall_json>yes</logall_json>
</global>Then restart the manager:
sudo systemctl restart wazuh-manager
If logs appear in archives.log but not in the dashboard, Wazuh needs a decoder to interpret the firewall event structure.
Add a decoder to:
/var/ossec/etc/decoders/local_decoder.xmlExample generic decoder:
<decoder name="Firewall_Generic">
<type>syslog</type>
<prematch>device_name="</prematch>
</decoder>
<decoder name="Firewall_Generic_child">
<parent>Firewall_Generic</parent>
<regex>device_name="(\S+)" timestamp="([^"]+)" log_type="([^"]+)" src_ip="([^"]+)" dst_ip="([^"]+)" protocol="([^"]+)" src_port=(\d+) dst_port=(\d+)"</regex>
<order>device_name,timestamp,log_type,src_ip,dst_ip,protocol,src_port,dst_port</order>
</decoder>Rules are added to:
/var/ossec/etc/rules/local_rules.xmlExample:
<group name="custom_firewall">
<rule id="100040" level="3">
<decoded_as>Firewall_Generic</decoded_as>
<description>Firewall Log Event</description>
</rule>
</group>Wazuh includes a built-in tool for testing decoders and rules. It is important to verify that all fields appear correctly and that the alert triggers successfully.
Run:
/var/ossec/bin/wazuh-logtestPaste a firewall log, for example:
device_name="FW" timestamp="2024-01-01T12:00:00+0100" log_type="Firewall" src_ip="1.2.3.4" dst_ip="5.6.7.8" protocol="TCP" src_port=1234 dst_port=443If everything is configured correctly:
Restart the manager afterward:
sudo systemctl restart wazuh-managerFirewall logs should now appear in the Wazuh dashboard.
A home SIEM is not just an educational project — it provides real visibility into security events occurring within your network. Wazuh is powerful enough for professional environments while remaining accessible for home labs and learning purposes.
Throughout this series, we will explore additional Wazuh configuration topics and other security products to build a sustainable and understandable security ecosystem.
Security cannot be bought in a box. Yet many organizations behave as if it can. Security software is often sold as an instant solution, but without expert handling it becomes little more than expensive shelfware.
In today’s cybersecurity landscape, tool sprawl is increasingly common — an obsessive race to buy more and more security solutions under the assumption that quantity equals protection.
Vendors present flashy dashboards and catchy acronyms, resellers promise perfect layered defenses, and executives with limited technical oversight approve purchases without understanding operational impact.
The reality is much simpler: without proper integration, skilled experts, management, and strategy, more tools frequently create less security.
Every security tool introduces additional agents, rules, logs, and alerts. Multiply that by dozens of systems and organizations often create chaos instead of visibility.
Many tools overlap in functionality, conflict with each other, or operate in complete isolation without sharing context.
In some environments, tools actively interfere with one another. Firewalls block legitimate traffic flagged elsewhere, DLP systems collide with backup solutions, and SIEM platforms fail to correlate events due to incompatible formats.
The result is reduced visibility, missed alerts, slower incident response, frustrated teams, and sometimes a dangerous false sense of security.
Security vendors frequently rely on fear, uncertainty, and doubt to drive purchases. Breach statistics and expensive “silver bullet” products are used to convince organizations that another purchase automatically means stronger protection.
This sales model works because many organizations lack strong technical leadership and trusted security advisors capable of evaluating whether tools are actually necessary or sustainable.
It is not uncommon for companies to spend hundreds of thousands of euros on products that remain unused or only partially implemented.
Cybersecurity functions as a chain where every component must communicate and support the others. If one component is misconfigured or disconnected, the entire chain weakens.
More tools mean more integrations, more maintenance, more patching, and more opportunities for misconfiguration.
Instead of coordinated defense, many organizations create fragmented and noisy environments where attackers exploit gaps between disconnected systems.
Another frequently ignored element is the end user. Security exists to protect people, yet many strategies overlook usability completely.
If tools are invasive, confusing, or poorly explained, users eventually bypass them, disable them, or unintentionally create additional risk.
Security tools are expensive for legitimate reasons including development, maintenance, and support costs. Vendors deserve profit, but profit should not outweigh responsibility.
Security should focus on education, realistic risk assessment, and alignment between technology, processes, and people.
Trusted advisors — whether internal security architects or external consultants — play a critical role in evaluating actual organizational needs and preventing unnecessary complexity.
Before purchasing another “silver bullet,” organizations should first improve the fundamentals:
Most breaches happen because of exposed systems, stolen credentials, or misconfigurations — not because the newest tool was missing.
Security starts with hygiene, not hype.
Security is not about accumulating tools. It is about making technology work together through strategy, expertise, and operational discipline.
Cyber defense is not a shopping list. More tools do not automatically mean stronger protection. Sometimes they simply create more confusion, cost, and vulnerability.
Organizations should shift their mindset from endless spending toward integration, hardening, and sustainability. That is where effective security actually begins.