PowerShell, PsExec, and RDP: How EDR distinguishes administrator actions from an attack
PowerShell executes dozens of times a day in your environment. PsExec is a standard tool in many administrator’s arsenals. RDP is the backbone of remote server administration.
Yet these same three tools top the list of the most frequently leveraged vectors in cyberattacks. They are effective precisely because they are ubiquitous, nad by default, no one treats them as a threat.
The question “PowerShell in company – how to recognize an attack?” has no simple “if X, then it’s a threat” formula. The answer requires in-depth analysis. This article demontrates how such an analysis works in practice, step by step, using the tools that administrators and analysts see most frequently in the EDR console.
Why a legitimate tool is not automatically a threat
The attack technique where an adversary uses native, trusted operating system utilities instead of custom malware is known as Living Off The Land (LotL). The logic behind this approach is straightforward: PowerShell, PsExec, or an RDP client are digitally signed, present by default in Windows environments, allowed by most security policies, and used daily by administrators. Instead of delivering a custom binary that might get caught by an antivirus signature, the attacker relies on a tool that is already there and inherently trusted by the system.
The question regarding legitimate tools used by cybercriminals is never “is this tool dangerous?” beacause the answer is always “it depends.” ESET Inspect logs the execution of PowerShell identically, whether it was run by administrator performing routine maintenance or by an attacker who just gained access to a workstation. The mere execution of a tool is only the starting point for analysis, not its outcome.
Example from an organization: An accountant executes PowerShell for the first time, and the process establishes a connection to an external server. The use of the tool alone does not prove an attack, but when combined with the rest of the context (discussed below), it takes on an entirely different meaning than the same command executed by a system administrator on an application server.
What is the significance of the user account?
An analyst reviewing an ESET Inspect detection related to PowerShell asks one key question:
Who performed this action, and does it fit this account’s behavioral profile?
A systems administrator’s account executing PowerShel a dozen times a day as part of standard duties has an entirely different baseline profile than a sales account that has never had any operational reason to touch the tool. The exact same command launched by these two accounts carries vastly different weight. Not because on account is “more trusted,” but because a deviation from an established behavioral pattern is a signal in itself, regardless of whether the specific command string looks benign.
The account’s privilege level and whether the action aligns with its assigned role also matter. A service account provisioned for a narrowly defined funcation that suddenly executes commands outside that scope is an anomaly requiring immediate explanation.
How to analyze timestamps, devices, and activity history
A suspicious RDP login is a prime example of how much temporal context and location matter when distinguishing normal activity from an event requiring deep-dive analysis.
ESET Inspect can flag an off-hours RDP login, but context is what reveals whether it was scheduled maintenance or the use of compromised credentials. An analyst evaluates several dimensions simultaneously:
- Has this account ever logged into this device via RDP before?
- Does the login timestamp fall within the user’s typical operational window or scheduled maintenance slots?
- Does the source IP address match previously observed geographic locations?
- Should the target device even be accessible via RDP for this specific account?
Individually, none of these indicators are definitive. An administrator might occasionally log in off-hours to apply an urgent hotfix. However, a login at an unusual hour, from a new location, via an account that has never accessed this service on that device before represents three independent anomalies overlapping simultaneously. This cumulative weight – rather than any single parameter – shifts the triage from “likely benign” to “requires escalation and verification.”
Why a single alert is not enough
No single alert, analyzed in isolation, provides sufficient grounds for a definitive decision.
A detection system responds to a pattern – often a specific:
- command,
- process,
- network connection.
However, the pattern itself conveys neither intent nor what occurred before and after. Reacting solely to an isolated alert typically leads to one of two pitfalls: misinterpreting routine operations as attacks (wasting time and potentially disrupting critical production workflows) or dismissing subtle stages of a real compromise.
To something that, in full context, turns out to be a routine operation (which costs time and may unnecessarily disrupt the production system’s operation).
Something that looks harmless in isolation, but when combined with other events, forms a coherent, concerning pattern.
This is why analysis never ends with reading the contents of a single notification. An analyst always traces the timeline backward to see what occurred on that account and endpoint prior to the event, while actively monitoring subsequent activity before making a final determination.
How an event sequence indicates reconnaissance or lateral movement
The scenario outlined below is a composite of common patterns observed across corporate environments. While not describing a single isolated incident, it illustrates how sequential analysis works in practice.
Initial vector: A marketing employee opends an email attachment on their workstation. Seconds later, PowerShell launches – from an account that has neer used the tool before. The process downloads additional payload code from an external IP. This initial detection, on its own, remains ambigos; it could theoretically be a legitimate, albeit unusual, operation.
Minutes later, the same account – specifically, a process executing within its security context – attempts to access the memory of the LSASS process (the Windows subsystem responsible for credential management). This serves as a critical second indicator matching standard credential harvesting techniques.
Next, PsExec activity appears on an adjacent file server – a remote command execution initiated by the account that was just subjected to credential dumping. PsExec is a standard tool used routinely for remote administration, but initiating it from a non-technical accoint to execute commands on neighboring infrastructure matches the lateral movement phase of an attack.
But using it form an account that had no reason for any technical activity just minutes earlier, in order to execute commands on another device, fits the pattern of lateral movement. More specifically – an attempt to propagate access from a single compromised machine to others within the same network.
Examined as an interconnected chain:
- Atypical PowerShell execution
- LSASS memory access attempt
- Outbound PsExec execution to another device from the same compromised account
The events align into a coherent attack sequence: initial access, credential accessm lateral movement. This distinction demonstrates the vital difference between reviewing alerts in isolation and correlating the entire attack narrative.
If you believe this risk is remote, consider the analysis published by CERT Polska, which recently demontrated how easily the cmd utility-built into Windows just like PowerShell – can be exploited without the user’s awareness.
Details on this threat can be found HERE.
When does an analyst escalate an event vs. close it?
The decision to resolve or escalate an incident is never driven by intuition. It relies on whether the available context sufficiently and definitively explains the observed activity.
An incident is closed when analysis of the account, device, activity logs, and execution chain yields a consistent, verifiable explanation. For example: an administrator was executing documented maintenance, the process is part of an approved script, and downstream actions match expected outcomes. This resolution is fully documented – not merely to clear a queue, but to ensure that identical benign context can be recognized faster in future reviews.
An incident is escalated when any core analytical element remains unexplained or when the event sequence matches a recognized threat profile (such as the multi-stage scenario above). In such cases, taking containment action – such as host network isolation – must weight the probability of compromise against potential operational disruption to business continuity.
In a model where response actions fall within a pre-agreed scope, atypical situations or those with an ambiguos business impact are escalated to the client’s designated representative. Decisions regarding actions with a tangible operational impact are never made in isolation from the understanding of how critical a given system is to the organization’s ongoing operations.
FAQ – Frequently asked questions about threat detection and EDR event analysis
Why do cybercriminals use legitimate tools like PowerShell or PsExec in attacks?
Attackers leverage built-in, trusted system tools to bypass traditional antivirus signatures – a methodology known as Living Off The Land (LotL). Instead of dropping custom malware binaries, adversaries use software native to enterprise Windows environments, allowing early attack phases to blend in with routine administrative tasks.
How does an EDR system (e.g., ESET Inspect) distinguish administrator activity from an attacker?
An EDR system avaluates the full context and behavioral profile of an account rather than merely the execution of a tool. The use of PowerShell by an IT administrator is standard practice. However, running the exact same tool form an accounting department account (which has never used it before), combined with an outbound connection attempt to an external server, represents a major anomaly and a signal for immediate response.
How can you tell if an RDP login is an attack rather than standard remote work?
An EDR system evaluates the full context and the account’s behavioral profile rather than just the execution of the tool itself. The use of PowerShell by an IT administrator is routine. However, the execution of the same tool by an accounting department account (which has never used it previously), combined with an attempt to communicate with an external server, is a significant anomaly and a trigger for immediate aciton.
What is sequence analysis in cybersecurity (lateral movement detection)?
Sequence analysis involves linking individual, often ambiguous events into a coherent attack chain. For example, downloading code, attempting to access credentials (the LSASS process), or using PsExec might appear to be false positives when viewed in isolation. However, when these three events occur sequentially on the same account within a short timeframe, thet definitively indicate lateral movement – an attacker’s attempt to propagate across to corporate network.
When does a security analyst close an alert vs. escalate an incident?
An alert is closed (and properly documented) when analysis verifies the legitimacy and context of the activity, such as scheduled maintenance. Escalation occurs when the activity remains unexplained or aligns with a known attack pattern. In the Polish MDR model by Perceptus, any decision regarding the final containment or network isolation of an endpoint always weighs how critical that system is to your organization’s business continuity.
If you are evaluating whether your internal team has the operational bandwidth and investigative expertise to conduct this depth of analysis for every alert generated in your console, that serves as the ideal baseline for reviewing your organization’s current triage capabilities.
Looking to enhance your cybersecurity?
Contact us!
Leave your details – we’ll call you back
Our specialist will get back to you no later than the next business day. You don’t have to fill in the message field, but a brief note about the topic you’re interested in will be a valuable hint for us.
