PowerShell Web Access | Exploring Threat and Detection Capabilities

5 min readOct 27, 2024

I recently discovered that Windows Servers offer the ability to enable PowerShell through a web interface, a feature known as PowerShell Web Access (PSWA) [1]. This capability piqued my interest as it not only supports remote server management directly through a browser but also introduces a unique attack vector for threat actors to leverage. This post explores the security risks of PSWA, how attackers may use it in their operations, and the options for detecting malicious use.

PowerShell Web Access (PSWA)

Originally released as part of Windows Server 2012, PowerShell Web Access (PSWA) provides a web-based PowerShell console, facilitating remote management of servers through a browser. This enables management of servers from non-Windows devices, allowing for management of multiple machines from a single interface,making it an attractive target for threat actors if improperly configured.

Installing PSWA requires IIS and operates over HTTPS, with username:password authentication [2]. Most notably, this facilitates console access to any system specified by the “Computer name” field, meaning the configured server can act as a gateway to more sensitive systems, such as Domain Controllers.

Although PSWA may seem specialised, it has been leveraged in recent cyberattacks against U.S. organisations by Iranian-based Advanced Persistent Threats (APT) as an execution technique (MITRE T1059.001) [3]. A CISA advisory, coded AA24–241A, specifically states these actors are enabling these features on Windows servers to carry out further reconnaissance, lateral movement, and remote command-and-control (C2), in attacks across several sectors, including finance, education, healthcare, and government.

Threat Capabilities

PSWA offers the same capabilities and functionality as any PowerShell console. While the CISA advisory provides limited details on its malicious use, a blog article by Michael Haag from the Splunk Threat Research Team outlines an example attack chain with common commands which adversaries employ [4].

(1) Obtain Credentials: If an attacker has obtained valid credentials and the PSWA is exposed to the internet, the attacker can authenticate via the console.

(2) Execution: Once authenticated, the actor is able to run commands against the host in which they connected to, enabling them to conduct further reconnaissance of the internal environment or download additional payloads:

Execution: Downloading a malicious payload

(3) Exfiltration: The attacker can gather and exfiltrate sensitive data, such as Active Directory information, network shares, users, etc.

(4) Lateral Movement: PSWA allows connection to other network machines through the “Computer Name” field or using console commands like Enter-PSSession.

(5) Persistence: The attacker can create users, create/modify scheduled tasks or Windows services to establish persistence within the environment.

Persistence: Creation of scheduled task and Windows service

The major benefit of leveraging PSWA is that it may not trigger the same alerts as traditional remote access tools, increasing the dwell time of the attackers within the environment. As it runs in a web-browser, Endpoint Detection and Response (EDR) solutions may not detect suspicious use, and depending on its deployment within the environment, it may allow attackers to blend in with legitimate administrative activities if it is widely used.

Detection Capabilities

As a general hunt search, looking for any logs to the URI path /pswa/* across IIS logs will serve as a good starting point for any suspicious access attempts to the PSWA or for establishing which systems have this enabled. This search can be refined by focusing on /logon.aspx for login events and /ExecuteCommand which show the command being executed.

PSWA also logs within Applications and Services Logs/Microsoft/Windows/PowerShellWebAccess/Operational, recording session-related events. For example, Event ID 769 will record “Session started” events, containing details of the session ID, target username, remote IP address, and destination system:

PSWA Logs (EID 769 — Session started): User logs in as Administrator from remote IP

Similarly, looking for EIDs 4625 (Logon Failure), 4624 (Successful Logon), and 4648 (Logon using explicit credentials) around the time of the EID 769 can also identify any unsuccessful login attempts alongside the intended remote destination server. Any successful logins will show as Type 3 — Network Logon.

Any events identified can be used to cross-correlate against host-based activity for PowerShell, specifically any wsmprovhost.exe processes. Since PSWA uses PowerShell remoting, any child processes will resolve back to wsmprovhost.exe. This is arguably the richest data source in terms of developing IoCs and identifying subsequent activity to pivot from. The most vital is the ability to view the commands executed via the PSWA console through Event ID 1 — Process Creation. This will help identify any tools downloaded to the system, as well as identify any attacker-controlled infrastructure being used to serve these files.

Sysmon Logs (EID 1 — Process Create): Base64-encoded PowerShell command via PSWA

Summary

Often is the case that remote management features provide flexibility and convenience for administrators but they also introduces significant risks, and PowerShell Web Access is no exception Attackers can exploit PSWA as an entry point to the network; however, robust detection methods for PowerShell activity are well-documented, and specialised PSWA logs allow cross-referencing with other sources, such as Sysmon and IIS logs. Ultimately, maintaining a proactive approach to security is essential for safeguarding systems that utilize PSWA.

PowerShell Web Access | Exploring Threat and Detection Capabilities

PowerShell Web Access (PSWA)

Threat Capabilities

Detection Capabilities

Summary

Further Reading

Written by 0xh4lpy