Locked Down, Not Locked Out: How I Escaped Yr Secure Operator Workstation

Locked Down, Not Locked Out: How I Escaped Yr Secure Operator Workstation

Speakers: Aaron Boyd, System Engineer, Liberty Energy

Conference: DEF CON

YouTube: https://www.youtube.com/watch?v=0r_trFFPVYc

Overview

In his compelling DEF CON talk, "Locked Down, Not Locked Out: How I Escaped Yr Secure Operator Workstation," Aaron Boyd, a seasoned system engineer at Liberty Energy with a distinguished background in pentesting at the NSA and Dragos, dismantles the common misconception that industrial control system (ICS) operator workstations are inherently secure. Drawing from over two decades of experience in red teaming and breaking into critical infrastructure, Boyd reveals a stark contrast between security expectations and the often-vulnerable reality of these systems across various industry verticals, including oil and gas, aerospace, and manufacturing.

Boyd's presentation serves as a critical wake-up call for organizations operating in the Operational Technology (OT) domain. He systematically exposes prevalent misconfigurations, security tool shortcomings, and cultural pitfalls that leave "locked down" workstations susceptible to exploitation by even unsophisticated attackers. By detailing specific, real-world examples of how he bypasses common security controls—without resorting to zero-day exploits—Boyd highlights that many vulnerabilities stem from "day one misconfigurations" and a compliance-driven mindset that overlooks actual adversarial tactics. This talk is essential for anyone involved in securing critical infrastructure, emphasizing the urgent need for a paradigm shift from passive trust to active validation and continuous challenge of security postures.

Background

▶ Watch: Speaker introduction and talk premise (0:00)

Operator workstations are the nerve centers of industrial control systems, typically found in control rooms where operators monitor and manage critical plant operations. The prevailing assumption among many organizations is that these machines are "locked down," implying a rigorous security posture. This expectation often includes strict Group Policy Objects (GPOs), application allow listing solutions like McAfee Solid Core, AppLocker, or Carbon Black in enforcement mode, the absence of local administrator privileges for operators, and robust alerting mechanisms. Furthermore, it's often presumed that security configurations are thoroughly documented, regularly reviewed, and immune to common IT security pitfalls.

However, Aaron Boyd's extensive experience as a pentester in OT environments paints a dramatically different picture. He contends that this "locked down" ideal rarely aligns with reality. The problem is multifaceted, originating from a confluence of factors across vendors, integrators, internal IT/OT teams, and an over-reliance on compliance checklists. Vendors, driven by the need to ship stable and fast products, often deploy default images with basic hardening that isn't tailored to specific organizational needs. Boyd points out that even "security packages" sold by vendors often follow the same exploitable patterns. Integrators, under immense pressure to deploy quickly, frequently reuse configurations, copying oversights from project to project. They often treat advanced security tools like allow listing solutions as "set it and forget it" antivirus, installing them without proper tuning or ongoing validation.

The most significant cultural issue Boyd identifies is a "checkbox mentality" towards compliance. Audit firms often ask if a control, such as allow listing, is enabled, but rarely if it has been successfully tested against adversarial behaviors. This leads to organizations "following the rules, just not the ones the attackers play by," as one CISO Boyd advised succinctly put it. This disconnect creates significant blind spots, leaving critical systems vulnerable to well-known attack techniques that exploit fundamental misconfigurations rather than sophisticated zero-day exploits.

Key Findings

▶ Watch: Secure workstations: reality vs. expectations (2:27)

Aaron Boyd's talk unveils several critical findings that underscore the pervasive vulnerabilities in "locked down" OT operator workstations:

1. GPO/AppLocker Bypass through Renaming: Boyd consistently finds that basic Group Policy Objects (GPOs) or AppLocker rules, intended to restrict executable execution, are easily circumvented. By simply renaming a forbidden binary like PowerShell or Command Prompt to an allowed executable name (e.g., alarms.exe), an attacker can gain arbitrary code execution, bypassing the intended controls.

1. Ineffective Application Allow Listing: Despite the presence of sophisticated allow listing solutions such as McAfee Solid Core, AppLocker, or Carbon Black, Boyd frequently encounters them operating in "learning mode" or with misconfigured policies. This renders them ineffective, allowing attackers to leverage Living Off The Land (LOTL) binaries like regsvr32, msbuild, or bitsadmin for malicious purposes without triggering alerts or being blocked.

1. Widespread Default Credentials: A persistent and alarming finding is the rampant use of default credentials. Boyd highlights that this issue plagues vendor appliances, operator terminals, and Human-Machine Interfaces (HMIs) alike. He cites an instance where he observed a specific (unnamed) vendor solution installed 39 times within six months, with 38 of those instances still using the exact same default username and password. This indicates a systemic failure in basic security hygiene, often reintroduced by integrators during reimaging.

1. Exploitable Login Scripts: Operator login scripts, while legitimate for automation, are frequently editable by non-administrative users. Boyd demonstrates how an attacker can modify these scripts to perform actions like creating a new local administrator account. By waiting for a legitimate administrator to log in, the attacker's malicious script executes with elevated privileges, granting them persistent administrative access.

1. Pass-the-Hash and Lateral Movement: Once administrative access is gained on one machine, and especially when default or reused credentials are in play, Boyd leverages tools like Mimikatz to perform Pass-the-Hash attacks. Confirming that the same credentials are used across multiple machines effectively grants him control over the entire environment, enabling widespread lateral movement.

1. Compliance Over Security: Boyd strongly criticizes the "checkbox mentality" prevalent in compliance audits. Organizations often prioritize meeting compliance standards (e.g., "Is allow listing enabled?") over actively testing their effectiveness against real-world adversarial tactics. This creates significant blind spots, as compliance does not equate to actual security.

1. DMZ as a Single Point of Failure: While network segmentation (e.g., the Purdue Model and DMZs) is crucial, Boyd warns against the over-reliance on a single jump server within a DMZ. This approach, while segmenting corporate from OT networks, concentrates all risk into one highly attractive target. Compromising this single jump server allows an attacker to hijack any user's session, effectively bypassing the segmentation benefits.

1. Operational Workarounds: A critical sociological finding is that security controls imposed without operator involvement are often circumvented. Operators, feeling that security measures hinder their job, will find ways around them, creating new vulnerabilities. This highlights the necessity of involving operations personnel in security decision-making processes.

Technical Deep Dive

▶ Watch: Bypassing GPO/AppLocker by renaming executables (3:40)

Boyd's presentation delves into the technical mechanisms behind these vulnerabilities, illustrating how seemingly robust security controls are often undermined by fundamental misconfigurations and a lack of adversarial thinking.

The GPO and AppLocker bypass is a prime example of flawed implementation. These controls are often configured to block specific executable filenames (e.g., powershell.exe) or binaries from certain paths. However, they frequently fail to enforce checks based on file hashes, digital signatures, or deeper contextual analysis. By simply renaming an executable—Boyd uses the example of renaming PowerShell.exe to alarms.exe—the GPO or AppLocker rule, which might only be looking for powershell.exe, is bypassed. This allows the renamed binary to execute with the user's privileges, effectively granting code execution. This technique is often effective because rule sets are created with specific known threats in mind, rather than anticipating variations or simple evasions.

The ineffectiveness of application allow listing solutions like McAfee Solid Core, AppLocker, and Carbon Black stems from two primary issues: being left in "learning mode" and poor policy configuration. In learning mode, these tools merely observe and log application execution without actively blocking anything, providing a false sense of security. When policies are configured, they often fail to account for Living Off The Land (LOTL) binaries. These are legitimate system tools that can be abused for malicious purposes, and because they are signed by trusted vendors like Microsoft, they often bypass allow-listing rules. Boyd specifically mentions:

• regsvr32: A command-line utility for registering and unregistering DLLs. Attackers can use it to execute arbitrary malicious scripts or DLLs by pointing it to a remote Scriptlet file.
• msbuild: The Microsoft Build Engine, a platform for building applications. It can be abused to execute arbitrary code by embedding malicious C# or PowerShell within a specially crafted XML project file.
• bitsadmin: The Background Intelligent Transfer Service (BITS) administrator tool, legitimately used for downloading and uploading files. Attackers can leverage bitsadmin to download malicious payloads from external sources, bypassing network egress filtering that might only block known malware signatures. Boyd had previously referenced bitsadmin in a past talk on living off the land in ICS/OT pentests.

The problem of default credentials is not merely an oversight but a deep-seated systemic issue. Boyd explains that integrators, often working under tight deadlines, frequently reuse standard build images or configurations that include these defaults. Even if an organization changes a password after an assessment, a subsequent re-imaging or update by an integrator can reintroduce the default, creating a recurring vulnerability. Boyd's finding of the same default credentials being used 38 out of 39 times for a specific solution within six months underscores the scale of this problem.

Exploitable login scripts are another critical vector. Many operator accounts are configured to run scripts upon login, which are often stored in locations writable by the operator or other low-privileged users. An attacker can modify such a script to include commands that create a new local administrator account. The script then lies dormant until a legitimate administrator logs into the machine. Upon their login, the modified script executes with the administrator's elevated privileges, granting the attacker persistent, high-level access. Once this access is achieved, tools like Mimikatz can be used to extract credentials (e.g., NTLM hashes or clear-text passwords) from memory. If these credentials are reused across multiple machines, attackers can perform Pass-the-Hash attacks, moving laterally across the network without needing the actual password, effectively compromising the entire domain.

Boyd also touches upon the vulnerability of privileged session managers or remote access tools like MoabXterm. While useful for managing remote sessions, these tools often store encrypted credentials or session keys in the registry. Boyd notes that these encryption schemes are "not hard to reverse engineer," allowing an attacker who gains local access to extract the keys and extend their reach to other systems accessible via the session manager.

Finally, while discussing network segmentation, Boyd offers a nuanced perspective on DMZs and jump servers. The Purdue Model advocates for segmentation between corporate and OT networks. A DMZ with a jump server is a common implementation. However, Boyd argues that if only a single jump server is used, it becomes a critical single point of failure. An attacker who compromises this server can potentially hijack any active session, effectively bridging the segmented networks and undermining the entire security architecture. This highlights that while the concept of segmentation is sound, its implementation often introduces new, concentrated risks.

Demo / Proof of Concept

▶ Watch: Ineffective allow listing tools left in learning mode (4:57)

While the live audience in the room faced technical difficulties preventing visual demonstrations, Aaron Boyd effectively narrated several compelling scenarios and real-world examples that served as powerful proofs of concept for his findings. He described these "screenshots" verbally, allowing the audience to visualize the impact of the vulnerabilities he detailed.

One primary narrated demonstration involved the GPO/AppLocker bypass. Boyd described seeing an error message indicating that a specific executable was blocked by a GPO or AppLocker policy. He then explained how, in a real-world scenario, he would simply rename a restricted binary like PowerShell or Command Prompt to an allowed name, such as alarms.exe. Upon executing the renamed file, the system would launch the shell, demonstrating successful code execution despite the active security policy. This illustrated the critical flaw in policies that rely solely on filename matching rather than more robust identification methods.

Boyd also provided a powerful statistical "demo" of the default credentials problem. He recounted how, within a six-month period, he encountered a specific (unnamed) vendor solution installed 39 times across various environments. In an astonishing 38 of those instances, the system was still using the exact same default username and password. This repeated observation served as undeniable proof of the pervasiveness and severity of this issue, highlighting how integrators or internal teams frequently fail to change default credentials, or reintroduce them during system rebuilds.

The login script manipulation was also narrated as a practical attack. Boyd described how he would identify an operator login script that was writable by a low-privileged user. He would then modify this script to include a command to create a new local administrator account. The "proof of concept" was the subsequent successful creation of the administrator account once a legitimate administrator logged into the compromised workstation, triggering the execution of the malicious script with elevated privileges.

Beyond these specific technical examples, Boyd shared a striking real-world anecdote from a recent assessment of a brand-new solar farm. Despite assurances from the customer that their new build adhered to all prior security recommendations, Boyd was able to compromise the entire site within 30 minutes. The critical vulnerability was that the individual solar inverters were broadcasting their own unprotected wireless networks. While physical access was required to connect to these networks, once on the inverter network, Boyd demonstrated the ability to shut off the inverters or modify their operations. This vivid example underscored the importance of verifying vendor claims and the often-overlooked physical and wireless attack vectors in OT environments.

Defensive Implications

▶ Watch: The persistent and widespread issue of default credentials (5:57)

Aaron Boyd's talk is not merely an exposé of vulnerabilities but a prescriptive call to action for defenders in OT environments. His recommendations focus on fundamental shifts in culture, process, and technical implementation:

1. Stop Outsourcing Accountability; Embrace Validation: The most critical implication is that security is an internal responsibility, not solely the vendor's or integrator's. Organizations must validate everything their vendors and integrators claim. This means moving beyond trust and actively testing deployments to ensure they meet security objectives, rather than waiting for an attacker to find the weaknesses. The cost of complacency far outweighs the cost of validation.

1. Treat Security Tools as Living Systems: Security solutions like application allow listing, endpoint detection and response (EDR), and network monitoring tools are not "set it and forget it" products. They require continuous tuning, testing, and challenging to remain effective against evolving Tactics, Techniques, and Procedures (TTPs). Regular review and adjustment of policies are essential to prevent them from becoming obsolete or easily bypassed.

1. Shift from Checkbox to Challenge Mentality: Compliance frameworks and standards are a starting point, but they should not be the sole drivers of security strategy. Defenders must adopt an adversarial mindset, proactively asking, "How would an attacker bypass this control?" and "What are the actual adversarial behaviors we need to defend against?" This goes beyond merely checking boxes to genuinely hardening systems against real threats.

1. Rethink DMZ and Jump Server Architectures: While network segmentation is vital (e.g., isolating corporate from OT networks), the common practice of using a single jump server in a DMZ creates a concentrated, high-value target. Defenders should consider implementing Privileged Access Management (PAM) solutions for credential management and Privileged Session Managers (PSM) with features like session recording. Boyd notes that screen recording, for instance, can quickly identify root causes of operational issues by providing an immutable audit trail. If a single jump server is unavoidable, implement robust multi-factor authentication, granular access controls, and continuous monitoring of sessions.

1. Involve Operations in Security Decisions: Security measures imposed on operators without their input are destined to be circumvented. Defenders must actively involve actual operators and operations personnel in the security decision-making process. By understanding their workflows and pain points, security teams can implement controls that enhance safety and security without unduly hindering operational efficiency, fostering a culture of collaboration rather than resistance. Creating a "space for failure and learning" allows teams to discover weaknesses before attackers exploit them.

1. Prioritize Vulnerabilities Strategically: Not all vulnerabilities are created equal. Boyd suggests a pragmatic approach to vulnerability management: focus on a select few critical vulnerabilities. His criteria are simple: "Does an exploit exist? Yes or no. Is it remotely exploitable? Yes or no." If the answer is "no" to both, resources might be better spent elsewhere. This helps avoid chasing every "medium" or "high" severity finding from a scanner and instead prioritizes risks that pose an immediate and actionable threat.

1. Implement Robust Credential Management: The pervasive issue of default and reused credentials demands urgent attention. Organizations must enforce strict policies for changing default passwords, implement Privileged Access Management (PAM) solutions to manage and rotate credentials securely, and conduct regular audits to ensure unique, complex passwords are in use across all systems, particularly operator workstations and vendor appliances.

1. Enhance Detection Capabilities: While prevention is ideal, Boyd emphasizes that detection is a must. This includes deploying sensors to detect physical intrusions (e.g., a door opening, a valve turning) as well as configuring Security Information and Event Management (SIEM) systems to collect and intelligently parse logs. The challenge isn't just collecting data but knowing "what to do with it." Focus on actionable alerts that indicate genuine security incidents, rather than being overwhelmed by noise.

Key Takeaways

• "Locked down" does not mean secure: The perception of security in OT operator workstations often diverges sharply from the reality, which is frequently riddled with misconfigurations and easily bypassed controls.
• Day-one misconfigurations are the primary threat: Most vulnerabilities exploited are not zero-days but rather fundamental errors like default credentials, weak GPOs, or misconfigured allow listing tools.
• Trust but verify: Organizations must stop blindly trusting vendors and integrators; instead, actively validate and test every security claim and deployed solution.
• Shift from compliance to challenge: Move beyond a checklist mentality towards an adversarial approach that actively tests defenses against real-world attacker tactics and techniques.
• Involve operators in security decisions: Engaging operations personnel is crucial to designing security controls that are effective and not circumvented due to hindering workflow.
• Prioritize actionable risks: Focus vulnerability management efforts on issues that are remotely exploitable and have known exploits, rather than chasing every scanner-identified vulnerability.

About the Speaker(s)

Aaron Boyd is a System Engineer at Liberty Energy, bringing a wealth of experience in securing complex operational technology (OT) environments. His professional journey includes significant roles at the NSA and as a pentester and Red Team member for Dragos, a leading ICS cybersecurity company. Boyd's passion for pentesting dates back to 2003, when he began as a hobbyist in high school. He describes breaking into refineries and other OT systems as "addicting," a testament to his deep engagement with the field. Known for his transparency and willingness to share insights, Boyd is a vocal advocate for challenging conventional security wisdom and fostering a more proactive, adversarial approach to OT security.