Jump to content
iwrconsultancy

Image File Execution (debug) registry keys

Recommended Posts

I'm finding that any debug entry in the Image File Execution registry section triggers a malware alert. The, I imagine,  reason is that some malware uses these keys to  resurrect itself on the launching of Explorer or other legit software if its own autorun entry is removed. However, the issue here is that these registry keys are also used by legitimate software.

 

Some legitimate security software uses this IFE mechanism to run browsers, etc with reduced rights such that downloaded malware cannot execute. In such cases, stripping the keys out will leave the computer in a condition of reduced security.

 

Perhaps the detection mechanism needs to be a little more specific about what executable the IFE call points to. In particular if it's a verified copy of StripMyRights.exe then it is probably legit, and removing it will knock out a security product rather than removing malware.

 

StripMyRights.exe: 65536 bytes

SHA-256: EAE41B6776B2090616DC9A0B85A3515FDB4EAB36F54B66407E81D087E3AB40ED

(Not sure if there are other versions around)

 

Scan Log:

 

Registry Keys Detected: 4
HKLM\SOFTWARE\MICROSOFT\WINDOWS NT\CURRENTVERSION\IMAGE FILE EXECUTION OPTIONS\CHROME.EXE (Security.Hijack) -> No action taken.
HKLM\SOFTWARE\MICROSOFT\WINDOWS NT\CURRENTVERSION\IMAGE FILE EXECUTION OPTIONS\FIREFOX.EXE (Security.Hijack) -> No action taken.
HKLM\SOFTWARE\MICROSOFT\WINDOWS NT\CURRENTVERSION\IMAGE FILE EXECUTION OPTIONS\OPERA.EXE (Security.Hijack) -> No action taken.
HKLM\SOFTWARE\MICROSOFT\WINDOWS NT\CURRENTVERSION\IMAGE FILE EXECUTION OPTIONS\SAFARI.EXE (Security.Hijack) -> No action taken.

Registry Values Detected: 4
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\chrome.exe|Debugger (Security.Hijack) -> Data: StripMyRights.exe /D /L N -> No action taken.
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\firefox.exe|Debugger (Security.Hijack) -> Data: StripMyRights.exe /D /L N -> No action taken.
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\opera.exe|Debugger (Security.Hijack) -> Data: StripMyRights.exe /D /L N -> No action taken.
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\safari.exe|Debugger (Security.Hijack) -> Data: StripMyRights.exe /D /L N -> No action taken.

 

 

 

Share this post


Link to post
Share on other sites

Hi,

 

These detections are because of setting a debugger with no purpose of "debugging", but rather to run another program instead. If you see this, then in most cases (95%), it's because of malware has set this as this is a common approach they use.

 

Hence why this approach for legitimate programs and using a debugger is not really recommended if not being used as a purpose of debugging.

Also see here: http://blogs.msdn.com/b/oldnewthing/archive/2005/12/19/505449.aspx - where MS warns for this. Its original goal/intention for this key is to debug a program, any other approach is not recommended.

 

That's why it's hard for us to know when it was set with legitimate purpose or not, so we go for the "detect after all approach", where for the handful of cases, where it's set for legitimate purposes, it can be safely ignored.

After all, removing that key doesn't break anything at all, you just need to have it re-create the debugger again if set with legitimate purposes.

 

So, in your case, I suggest you ignore these detection (you can assign to whitelist them).

Share this post


Link to post
Share on other sites
I suggest you ignore these detections

 

The issue is not whether we ignore them but whether users do.

 

The IFE settings are part of a security utility we publish, http://sf.net/projects/softwarepolicy and this raises two problems:

1. When the entries are deleted it downgrades the security of the computer, such that it is more vulnerable to browser drive-bys.

2. When a user sees the report they will think our software contains malware, spyware or such. We have already had a few accusations of such.

 

From what you say, it would not seem to make any difference if the executable acting as debugger is whitelisted, that any such registry key is flagged as malware and the the only way to prevent that is to whitelist the registry key itself. The problem with that approach is that the registry key names cannot be predicted in advance. If a user adds Safari to the limited-rights list, for example, they would expect the software policy to cover that browser.  In fact, it will only be covered until a Malwarebytes scan, at which point the browser will become able to execute drive-bys once more.

 

As regards the legitimacy of our using this approach, we did check carefully on Microsoft's Technet resources that IFE entries are a permissible modification to the registry. They are. It seems we are in a can't win situation over this kind of issue these days. Do the thing by the book, and you still, unilaterally, told that you are doing things wrong. A workaround from us using an alternative approach would involve a lot of recoding... and I really question if it's worth the efforrt since after x man-hours of coding/testing, we could be hit by another 'You can't do that, even though the book says you can!' scenario. In which case, much work and time wasted for nothing. 

 

Basically, with the frequency of false AV positives these days the coding of any small Windows utilities is becoming an unsustainable activity. Especially if the false detections are tarnishing our reputation as a desktop support provider, which situation could be losing us paid work. 

Share this post


Link to post
Share on other sites

Hi,

 

I have sent you a private message via this forum. Please check your Private messages on top.

 

Thanks

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...

Important Information

This site uses cookies - We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.