PowerShell Logging: How to Identify Suspicious Activity

PowerShell Operational log

The topic 'PowerShell Operational log' is a central part of working with PowerShell Logging. It is recommended to break it down into three questions: what is the input, what decision do you want to make, and what evidence is sufficient to justify it. These questions prevent automatic use of a tool without understanding its purpose.

In practice, record Event 4104 Script Block Logging, Event 4103 Module Logging, Operational channel, Command line and parent process, AMSI/EDR context, compare to expected behavior, and define at least one Pivot. The result should be verifiable by another analyst, including limitations and next steps.

Script Block and Module Logging

At this stage, define what evidence is needed to answer the investigative question. For PowerShell Logging, the basic points are Event ID and Provider, Computer, User and Logon ID, Process, Parent and Command Line, Source IP, Workstation and Logon Type. For each source, document owner, retention range, time zone, ingestion delay, and potentially missing fields.

Collection quality is not measured by the log 'arriving'. You must check Completeness, Latency, Parsing, Duplicate events, and time synchronization. A Canary test or a known lab event allows verifying that the action appeared in the source, passed through the Pipeline, and is searchable in the correct fields.

Transcription and 4688/Sysmon

The topic 'Transcription and 4688/Sysmon' is a central part of working with PowerShell Logging. It is recommended to break it down into three questions: what is the input, what decision do you want to make, and what evidence is sufficient to justify it. These questions prevent automatic use of a tool without understanding its purpose.

In practice, record Event 4104 Script Block Logging, Event 4103 Module Logging, Operational channel, Command line and parent process, AMSI/EDR context, compare to expected behavior, and define at least one Pivot. The result should be verifiable by another analyst, including limitations and next steps.

Investigation Patterns

An investigation of PowerShell Logging begins with formulating a Hypothesis: what behavior explains the finding, and what evidence will confirm or refute it. Then, expand the time window, verify the entities, and look for a sequence before and after the event.

Good correlation combines at least two types of information from Event 4104 Script Block Logging, Event 4103 Module Logging, Operational channel, Command line and parent process, AMSI/EDR context. For each finding, state what it proves, what it does not prove, and what the next step is. If the data is insufficient, mark it as Unknown and do not turn absence of evidence into evidence of absence.

Tuning for Admin Activity

Improving PowerShell Logging must begin with a Baseline. Measure volume, rate of useful cases, investigation time, missing sources, and reason for closure. A change that reduces Alerts but hides real activity is not a success.

Tuning options include threshold, time window, focused Allowlist, asset Context, Suppression, and an approved process-based exception. Each exception should have an owner, validity period, and cancellation conditions. After the change, run a Test corpus and compare before/after.

Unique Test Foci

On this topic, it is recommended to proactively build a focused evidence map. The main test foci are: Event 4104 Script Block Logging, Event 4103 Module Logging, Operational channel, Command line and parent process, AMSI/EDR context. The list is not an automatic Checklist; each item is chosen because it can link an entity, action, and time or explain legitimate behavior.

• Event 4104 Script Block Logging: Define what the expected value is, what will be considered an anomaly, and what additional source will verify the finding.
• Event 4103 Module Logging: Define what the expected value is, what will be considered an anomaly, and what additional source will verify the finding.
• Operational channel: Define what the expected value is, what will be considered an anomaly, and what additional source will verify the finding.
• Command line and parent process: Define what the expected value is, what will be considered an anomaly, and what additional source will verify the finding.
• AMSI/EDR context: Define what the expected value is, what will be considered an anomaly, and what additional source will verify the finding.

If one of the foci is unavailable, document the gap and choose an alternative. For example, if the Process identifier is not stable, you can use time, Host, User, and Parent; if the Payload is encrypted, use Metadata, volume, frequency, and TLS/DNS context.

Recommended Workflow

1. Define the Scope and a single working question regarding PowerShell Logging.
2. Document the data sources and required evidence: Event 4104 Script Block Logging, Event 4103 Module Logging, Operational channel, Command line and parent process.
3. Create a short Baseline of normal behavior or expected outcome.
4. Perform the minimal test in a lab environment and save time, input, and output.
5. Build a Timeline or comparison table and separate fact from interpretation.
6. Pivot to an additional source to confirm or refute the initial explanation.
7. Summarize the decision, limitations, recommended action, and Retest criteria.

Practical Scenario

The chosen scenario is investigating a simulated script that downloads a file in a lab. The purpose of the exercise is not to prove attack capability, but to practice safe collection, comparison, and documentation. Before starting, define simulated data, time window, and expected outcome.

At the end of the exercise, submit a product that another analyst or tester can review: a screenshot or Export of the evidence, a short Timeline, initial assumption, verifying evidence, limitation, and recommendation. When there is insufficient evidence, the correct conclusion is that the scenario has not been proven.

Practical Checklist

• ✓Check and document: Event ID and Provider.
• ✓Check and document: Computer, User, and Logon ID.
• ✓Check and document: Process, Parent, and Command Line.
• ✓Check and document: Source IP, Workstation, and Logon Type.
• ✓Check and document: Group/Privilege changes.
• ✓Check and document: Sysmon ProcessGuid or SessionGuid.
• ✓Note Time zone, tool version, and collection time.
• ✓Save raw data before filtering or changing.
• ✓Write what the finding proves and what is still unknown.
• ✓Define owner and next action with a deadline.

Common Mistakes

• Relying on Event ID without fields.
• Confusing Logon with the attack source.
• Ignoring Logon Type.
• Linking Processes only by PID.
• Assuming all PowerShell is malicious.
• Closing an event without checking the Domain Controller.

Summary and CTA

PowerShell Logging: How to Identify Suspicious Activity is a topic that combines technical knowledge with work discipline. Start with a question, collect only relevant evidence, maintain context and time, and choose an action that can be justified and re-examined.

In HPI's Cybersecurity & AI track, these principles are practiced using systems, logs, and labs. A natural next step is to move on to the linked articles, complete the lab exercise, and save the output as part of a professional portfolio.

FAQ