Windows Security Iexplore.exe

[Francisca Noggles]

These are all enabled -I didn't set those myself, a fellow developer on the team did. Everybody on the same network is able to access the site without any issues, except for one user who is on another domain -don't know if it's a trusted or not.

When that user on the other domain tries to access the site, IE displays a security dialogue asking for credentials. My site doesn't make use of any windows credentials, so I don't really need to know the Windows username and password for the visitor. The dialogue that is displayed by IE doesn't block the user from accessing the site, in fact no matter what she does (enter some blah blah credentials, or even cancel out off the dialogue) the site will still open as intended and she will be able to use the different functionality of the site.

Since cancelling allows her to view the site still, I bet that it's one of the dependencies on the page that requires authentication. It may be .css, .js or maybe an ad, or something that her environment adds to the page via a proxy server.

You can test this by giving her a test.html page that simply says "Testing". If she can review that without a prompt, then my theory is correct. If my theory is correct, then review the page to find out which file isn't allowed, and trace that down to find out why.

On your IIS server, use Explorer to find the Windows directory where your web site files are stored, right-click, select Properties, go into the Security tab, and make sure that YOURSERVERNAME\Users have at least some permissions on this folder.

But in Windows 10, I cannot. The program doesn't recognize it as an alert and just pauses until it terminates. I've tried researching similar issues but have had no luck. This is still working in IE as well, not in Edge.

You can use Raj's answer but you don't need to use the Sikuli framework. You can use the java.awt.Robot to send keystrokes to the Windows security popup. In the example below the robot is keying a user ID of "U", then tabbing to the password box, keying a password of "P", and keying the Enter key to close the popup.

I have struggled initially with Windows Security Alert in Windows 10 IE 11. I tried using AutoIT (not able to identify the alert but can work with Tab press), SwitchToAlert, AuthenticateUsing, Passing UID and PWD in URL etc, but they didn't work for me. At last, using Sikuli in Selenium worked. Below is the code snippet:

If your application keeps loading until credentials are entered then you will get a pageLoadTimeout exception before executing the Sikuli scripts. To overcome this exception I tried the below code and it works:

I was able to solve the IE Basic Auth Problem in IE 11 (Windows 10) by making registry changes. As described in this blog post, iexplore.exe and explorer.exe keys need to be created in the following locations:

Got a number of Endpoint security 8.1 boxes on which I've loaded the KB6119 HIPS policy. Since I had a script that starts Internet explorer, I made a new policy to append a rule that allows wscript.exe to start C:\Program Files\internet explorer\iexplore.exe (note especially how the underlined part is written). For the record, the script is named script.cmd and contains:

This worked on a couple of systems. However, I was receiving HIPS alerts from other systems. Upon closer inspection the problem was that in the scripts used in those systems, I had written script.cmd with different casing in the words internet explorer, ie:

It seems that the HIPS rule differentiates between these two cases, although it shouldn't (as far as I know, Windows file system names are case insensitive, therefore the first rule should match the 2nd case as well.

The scenario is this: we have a Checkpoint VPN software that does not run well under Windows 10. In order to be able to actually utilize it successfully, a user has to start internet explorer as an admin.

This is problematic as you can understand, since this opens a full can of worms. So we've been instructed to follow this approach: install powertoys and create two scripts. One that launches internet explorer named script.cmd:

Also note that this elevate process not only changes IE permissions but appears to also start it. Existing Eset anti-ransomware rules will not monitor any process startup activity from elevate.exe. HIPS rules are not global in nature. For example; they will monitor IE startup from cmd.exe. They will monitor elevate,exe startup from cmd.exe. If elevate.exe is allowed to start by cmd.exe, anything that elevate.exe starts will be allowed to run. A separate HIPS rule needs to be created to monitor elevate.exe process startup.

In mid-May 2024, we tracked this updated Void Banshee campaign using internal and external telemetry. The Void Banshee group used similar tools, tactics, and procedures (TTPs) that involved abusing internet shortcuts (.URL) and Microsoft protocol handlers and URI schemes, including the MHTML (MIME encapsulation of aggregate HTML documents) protocol which was able to access Windows system-disabled Internet Explorer.

In the attack chain shown in Figure 1, the threat actor leveraged CVE-2024-38112 to execute malicious code by abusing the MHTML protocol handler and x-usc directives through internet shortcut (URL) files. Using this technique, the threat actor was able to access and run files directly through the disabled Internet Explorer instance on Windows machines. This MHTML code execution vulnerability was used to infect users and organizations with Atlantida malware.

Internet Explorer (IE) has officially ended support on June 15, 2022. Additionally, IE has been officially disabled through later versions of Windows 10, including all versions of Windows 11. Disabled, however, does not mean IE was removed from the system. The remnants of IE exist on the modern Windows system, though it is not accessible to the average user (Figure 2).

If users attempt to execute the IE executable (iexplore.exe), instead its replacement, Microsoft Edge, opens. For users and organizations that need to access sites and workloads through Internet Explorer, Microsoft has provided IE mode for Microsoft Edge (Figure 3). IE mode for Edge contains some IE-specific functionality, but operates inside the Microsoft Edge sandbox, which in theory provides enhanced security for the end user.

In this campaign, the ZDI threat hunting team discovered and analyzed samples exploiting CVE-2024-38112, which we disclosed to Microsoft. These samples could run and execute files and websites through the disabled IE process by exploiting CVE-2024-38112 through MSHTML. By using specially crafted.URL files that contained the MHTML protocol handler and the x-usc! directive, Void Banshee was able to access and run HTML Application (HTA) files directly through the disabled IE process. This method of exploitation is similar to CVE-2021-40444, another MSHTML vulnerability that was used in zero-day attacks. This method of using the disabled IE process as a proxy to access sites and scripts is especially alarming, as IE has historically been a vast attack surface but now receives no further updates or security fixes.

Void Banshee used zip archives containing copies of books in PDF format, along with malicious files disguised as PDFs in spearphishing links (T1566.002), on online libraries, cloud sharing sites, Discord, and a slew of compromised websites.

Some PDF lures we uncovered during our analysis of the Void Banshee campaign include textbooks and reference material such as Clinical Anatomy, which suggests the campaign is targeting highly skilled professionals and students who often use reference materials and places where digital copies of books are collected (Figure 5). In the case of exploiting CVE-2024-38112, Void Banshee changed the default icon of an internet shortcut file to that of a PDF file to entice the victim into executing it.

In this attack, CVE-2024-38112 was used as a zero-day to redirect a victim by opening and using the system-disabled IE to a compromised website which hosted a malicious HTML Application (HTA), as shown in Figure 7.

In the URL parameter of the internet shortcut file, we can see that Void Banshee specifically crafted this URL string using the MHTML protocol handler along with the x-usc! directive. This logic string opens the URL target in the native Internet Explorer through the iexplore.exe process.

As mentioned above, the internet shortcut file that exploits CVE-2024-38112 points to an attacker-controlled domain where an HTML file downloads the HTA stage of the infection chain (Figure 8). Using this HTML file, the attacker can also control the window view size of the website through IE. This is used by the threat actor to hide browser information and to mask the downloading of the next stage of the infection chain from the victim. Void Banshee specifically crafted this HTML file using window size elements to control the window size of IE.

Once this URL is contacted via IE, it attempts to open the malicious HTA file, prompting the user to open or save the HTML application (Figure 9). This behavior is unique to IE in that HTA files are opened by default, whereas modern browsers like Microsoft Edge or Chrome do not have the default open action.

The HTA file contains a Visual Basic Script (VBScript) that decrypts XOR encrypted content with key 4 and executes the content using PowerShell (Figure 11). This script uses PowerShell to download an additional script hosted on a compromised web server and executes the command using the PowerShell irm (Invoke-RestMethod) alias and iex (Invoke-Expression) alias commands. Finally, the script creates a new process for the downloaded script using the Win32_Process WMI class.

Next, the script retrieves the handle of the console window using the GetConsoleWindow method and stores it in $danger5646. It then calls ShowWindow with the window handle and the parameter 0, which hides the console window. This technique is often employed in malware to run without displaying any user interface.

c80f0f1006