Keyboard.exe - Should I be Worried?

I noticed in my Defense+ log that keyboard.exe tried to execute. Now it shows that it was in my download folder and I certainly didn’t explicitly download it.

Defense+ said it auto sandboxed it but I don’t recall seeing any Defense+ popups for it. I am concerned about the hooks it installed? Also Defense+ created a rule for it but execute was ask and everything else was block.

I searched my HDD for keyboard.exe and no instances were found. So I purged the rule Defense+ created for it.

Still concerned about the fact no popup was received and those hook installations plus the direct keyboard access message.

[attachment deleted by admin]

what happens if you select more and show up more info on alerts displayed.

I think I tried that and it didn’t show anything. I will try later this afternoon when I get back from work.

I did some further checking, and this keyboard.exe occured very close to the time I did a reboot. So I am speculating that if Defense+ catches something during the boot process, no desktop alert would be given?

I also checked in System32 diirectory for those .dll files shown in my prior attached Defense+ log. I did not find any. However, it dawned on me that I might not have searched for all hidden files, etc. So I will also repeat the Search later this afternoon.

Oh, one other point. Saturday eve. when I was checking my AOL e-mail, I found what was an obvious phishing attempt. One of those, “you have a USPS Priority Mail Message” baloney. I didn’t open it, but I did right click on it to view it’s HTML code. I could see the virus code in the attachment. Wonder if I shot myself in the foot playing with that e-mail?

For what it’s worth, keyboard.exe is not a native Windows 7 file. The on screen keyboard is called osk.exe and is found in Windows \system32. Dwmapi.dll is the Desktop Windows Manager api, and is a library used by many applications that interact with the desktop environment.

what happens if you select more and show up more info on alerts displayed.

Yes, “More” showed that access to dwmapi.dll was denied. Question is did Comodo deny it or DEP?

It appears to me that keyboard.exe did run in the sandbox with limited privleges. There was a Defense+ policy rule created of “ask” created for it. Does Comodo create Defense+ policy rules for sandboxed items?

So was “limited” trust level adequate for this intrusion?

D+ did deny it. When files get sandboxed there are also a couple of D+ restrictions put upon those files. Installing a Global Hook is one of them. When you don’t answer the alert D+ will deny the action; that is the Default Deny principle.