Windows Explored

In an earlier post, I blogged about a request where the user no longer wanted to be annoyed by the IE’s security information prompt when visiting secure sites and the problem involved in trying to circumvent this setting in an environment where this is controlled via group policy. This time, I came across an issue where the user was being interrupted by the same prompt when visiting an internal resource that should not be displaying the IE “Security Information” prompt for secure sites.

This actually became quite annoying because each time the site was navigated, the message would pop up, so a simple document query, Back action in IE, or hyperlink to another page in the site would throw up this prompt. After stumping the tech involved, I was asked to assist. At this point, basic troubleshooting covered resetting Internet Explorer settings and disabling all add-ons. We also made sure that the Local Intranet and Internet Zones were populated with the correct URLs. And as a workaround (oddly enough), we were able to change Display Mixed Content in the IE security setting from Prompt to Enable in the Internet Zone. But these settings were only temporary as group policy would reset them so the cause needed to be found and corrected.

I was already familiar with circumventing this policy setting from the earlier post linked above, so I already knew what registry keys and values I needed to look at. The tool I would be using would be Process Monitor again. I wanted to see what was happening when the security prompts were popping up when IE went to the internal URL so I set a filter to display only activity from registry operations in iexplore.exe. When complete, I captured the trace and did a search for the registry key and value where Display Mixed Content was found using Ctrl+F to search Zones and 1609:

I double-clicked the highlighted operation above and went into the Stack tab to look for anything out of the ordinary and saw this:

When looking at the call stack, you read from the bottom to the top. You can see that bho_project.dll is the first module called in this operation. I opened some other random operations and could see the same dll in the start of the call stack as well. The name and location of the dll sounded suspicious. To confirm my suspicion, I right-clicked the entry in the stack and selected Search Online from the context menu. This was confirmed when the Internet search page opened a search using a not so common search engine:

Some more research revealed this search page and file were associated with some kind of FaceBook theme malware\browser hijack. You can also see the properties of the dll directly from the Stack tab:

I looked in the folder where the dll resided and saw there was an uninstall exe file. From Add or Remove programs there was also an option to uninstall. Of course, you don’t actually want to run this uninstall. No malware wants to uninstall itself willingly. Instead of uninstalling, I deleted the folder and then followed up with a couple other tools for further detection and cleanup. I Started with Process Explorer to look for any suspicious processes. Not finding anything here, I assumed the module was being loaded at Startup so I turned to Autoruns and found the object in the Browser Helper Objects for Internet Explorer:

Next, I needed to reset the IE search page and scopes. To do this, I first needed to delete all references to StartSearcher in the registry, of which there were several. After resetting the home page, I tested IE by visiting the problem URL and the security prompts no longer opened up for the internal URL.