Anti-keylogger Undetected

I just installed Process Guard (Paid Version). It does not seem to detect my Anti-keylogger program even in learning mode, and with reboot. I added it manually to security list and protected programs and gave it privilege for terminate, modify and read, and protected it from terminate and modify.

My question, How does this process go undetected? I know it does start up even before the operating system. I'm running Win XP Home.

Dave

 

Are you saying that BEFORE you added it manually into PG it was able to load up without PG interfering?

 

Hi casper1,

If you try to add the keylogger with learning mode _off_, and Block Global Hooks _on_, the ProcessGuard should alert you that the keylogger is attempting to obtain global hooks. Are you saying that this is not happening? ProcessGuard is prevention-oriented, as opposed to detection oriented, so it will not give you any alerts if you have given the keylogger permission, but it will alert the first time you try to install - assuming that learning mode is off.

I would be interested in hearing more, if this is not what you are experiencing.

Rich

 

Hi casper1,

Assuming you had Execution Protection enabled, if you had to manually add it to the security list, I suspect your anti-keylogger is already running before PG establishes itself. When you said it starts up "even before the operating system", I read that to mean it's started as a service once before user logon (as opposed to a program/service that's restarted each time you logoff/logon). If that's the case, I think that PG will be unable to control its start up behavior.

The above highlights one of the reasons that, for PG to be effective, a system must be clean before it is installed. It's also a good reason to have a registry monitor. That said, I think it's also evidence that PG could still be improved. I (and probably others) have suggested that it would be a very good thing for PG to be fully functional before a user is allowed to logon. That would not, however, be a trivial change to make. So far, I'm not aware of any response from DCS.

Regards

 

Hi earth1,

If, what you say is correct, and the keylogger was already installed and active before ProcessGuard was installed, it would still be necessary for PG to give Global Hooks permission to the keylogger. If PG did this, while in Learning Mode, it should be listed as such in the protection list - and could be detected in this manner. I would be interested in more information on this, since if it is not working as I expect it to, then I am missing something in my understanding of PG. Should be interesting to hear more.

Rich

 

Hi Rich,

My "theory" is that if the keyboard hook was set before PG was in position to detect that change, then PG has no way to figure out, after the fact, that it happened. If the anti-keylogger's hook is in place before the logon screen is displayed, then I think PG has no chance of detecting that action.

This is definitely one of the subjects that I'd like to hear more from DCS on, but I also understand their reluctance. Perhaps we'll hear from someone with more certain knowledge.

 

Hi earth1,

I understand what you are getting at, and I too would like to hear more about this. One of the things I noticed about using Security Task Manager, is that it will indentify all of the resources that a given program is using - e.g. global hooks, so it is possible for STM (and its real-time component called SpyCop) to detect what is going on. I would guess that PG can do the same, but I will wait to see what the more knowledgeable members of this forum have to say. Of course, I could just test it myself, which is what I may end up doing.

Rich

 

Microsoft used to have a tool called BootVis available that allowed you to trace the startup process and graph out what is loading and in what sequence. This way you could see what's loading before ProcessGuard or exactly when your firewall is loading etc.

Unfortunately Microsoft no longer offers this tool for download since the optimization routines are now part of XP's performance monitoring. That's why SP2 for XP booted like old W2K for the first couple of boots after install but got better over time. But if you hunt around for "BootVis" online you may still find it, but maybe not. MS is pretty good about making sure tools they eliminate are no longer available online. The graphing out of the boot up sequence is quite informative. But it doesn't allow you to change the load order, only "optimize" it via a defrag and other optimizing routines.

There are some things you can try however, I noticed on my machine that if I disable certain things like my LAN network connection, so I boot with no connectivity, ProcessGuard loads much much earlier than normally, catching everything that normally loads and normally it starts pretty early. But under normal boots with the LAN enabled some stuff does indeed load earlier or faster than ProcessGuard.

In order to get XP to boot as quickly as possible since people complained about how lethargic the W2K boot process was, MS turned it into a mad rush of execution at startup and anything can affect the load order now. That's also the reason why network connections turn on so late in the boot process now in XP, to allow your machine time to load all your security first before the network connection is switched on.

There really isn't much you can do about load order in the XP boot process. We all wanted faster booting, but it came with a price tag. ProcessGuard seems to do it's best at trying to load as early as it can, but some stuff can load earier and set it's hooks before PG is initialized.

 

Are we tracking this one right?

Casper1 is saying: "It does not seem to detect my Anti-keylogger program"

Are we talking about the AKL program (the one by that name) itself? Or another anti-keylogging program?

Or what? Pete

 

Thanks everyone for the responses. I'm new to Process Guard so I'm kind of just observing to learn the processes that run on my system, and how they interact with stuff. I'm sure I'll have questions on how to handle some of the alerts as I learn more about my system and how it normally functions. I do believe my system is very clean. I use all the top notch security products, and Process Guard was a great addition to my arsenal. I am a security moderator on another forum so I do take security very seriously.

I believe that earth1 has hit the nail on the head. Anti-keylogger is the very first thing to load even before the operating system. This allows it to block keylogging trojans at the earliest stage. So I guess unless Process Guard's architecture changes, it couldn't capture this. I just added it manually myself to the security list, and started it again manually to get it on the protected list. Then I added terminate privileges since that is it's base functionality. Anti-keylogger allows you to exclude trusted keyloggers from termination like for instance roboform so I can control termination at the application level inside anti-keylogger, only terminating the malicious processes.

Process Guard is a great product. I tested the free version for a week, then decided to purchase. It has just a bit of a learning curve. I wouldn't recommend it to someone that is a novice. It's really a System Administration tool that allows you to make decisions, and that could be dangerous for some people, but great for those that can grasp the concepts.

casper1

 

But wait a minute... if your Anti-Keylogger program was able to load before PG and basically beat PG's defense... what happens when the next trojan loads up in this same way and takes advantage of this weakness??

 

Hi suave,

In this case, casper1 gave his anti-keylogger permission to load, and therefore it was able to register itself to the system. Any new trojan, would first have to find a way to get passed PG in order to install itself into the system. PG would give an alert if this were to happen, and it would be up to the user to decide whether or not to allow the program (in this case the trojan) to execute. Of course, as casper1 indicated, this requires that the user make the right decision by being knowledgeable about what is happening.

One of the reasons, I am also running RegDefend and Prevx is to give myself a "second chance". If I accidently allow a trojan installer to execute, it would (hopefully) be caught by RegDefend (as it tries to install itself into the registry) and/or by Prevx as it tries to implant itself into one of the protected directories. But all of this is backup for my primary defense which is PG and so far PG has detected everything before it had a chance to do anything.

Rich

 

Casper1, if you're up for a quick experiment, perhaps you could try changing PG's security setting for AK to be "Deny Always" and see if it still manages to start. That should establish with certainty what does happen (though perhaps not why).

 

Yeah casper, can you please try what earth1 said above and report back with the results?

 

Ok Guys,

I'll give it a try in the morning and post as soon as I know. It's time to go to sleep right now.

casper

 

If Anti-Keylogger was installed prior to the recent addition of PG, then it's quite posible PG didn't detect it (that is, after all, why it's suggested to install PG only on a "known clean system" - in your case, we're speaking of a benign or beneficial program - it could just as easily have been pre-existing malicious malware, instead) - although I'm not sure (without seeing the PG log beginning with the moment it was installed) that it actually didn't detect the running components of AKL but - since it was in "Learning Mode" - it simply let everything fly. (That's what "Learning Mode" is designed to do). There still should have been log entries made while in "Learning Mode" about what it allowed, though.

Without "Denying" rights to AKL, you might want to simply "Remove Application(s)" on everything regarding AKL from PG's "Protection" and "Security" tabs .

Start all over by then checking for updates for AKL (I guess it has that function, right?) and/or try running a scan with AKL. (Remember this will be after you remove any and all permissions for AKL within PG) and see what kind of alerts you get (if any).

It'll be interesting to hear of your results. Pete

 

Similar situation here. I have 3 startup registry apps that came with my laptop. They make the extra buttons on my laptop's front and special proprietary hotkey buttons function and they need to install hooks to work correctly. I never gave them the right to install global hooks and ProcessGuard's learning mode never caught it because they always loaded before PG and installed their hooks.

Months later, when I disabled my LAN connection one day and rebooted, I noticed ProcessGuard flashing that these 3 apps were blocked from installing hooks and they didn't work right without them, so I gave them that ability after the fact and rebooted. If I boot with my LAN enabled, these apps load earlier (maybe the correct term is that they load faster) than ProcessGuard does. So it's very possible to install hooks, services drivers etc., if it loads before ProcessGuard does. This has been discussed here before, it's nothing new. It's a limitation of Windows not allowing a load order in the boot process.

I ran bootvis to see what the load order is on my machine and ProcessGuard loads very early in boot process (so do my antivirus, registry protection and firewall), but they are not first, but very close to first.

That's why I also supplement PG with other security applications including registry startup protection and folder locking of my startup folder. I still consider PG to be invaluable despite this flaw in XP. Actually, it's all the more reason to use PG while running to help prevent malware from getting to your startup in the first place. But I'm curious to see if it's the same situation also.

 

Hi

This thread should answer your question a to why PG didn't detect it.
I have tried it on my system with regdefend and that detects the drivers but I have not tried it on my system with PG installed yet.

https://www.wilderssecurity.com/showthread.php?t=75773

Bruce

 

I spent some time testing Anti-keylogger on a machine with Process Guard already installed. PG logs the following during the install:

Sat 16 - 23:33:25 [EXECUTION] "c:\documents and settings\******\desktop\ak_setup.exe" was allowed to run
[EXECUTION] Started by "c:\windows\explorer.exe" [500]
[EXECUTION] Commandline - [ "c:\documents and settings\******\desktop\ak_setup.exe" ]

Sat 16 - 23:33:26 [EXECUTION] "c:\docume~1\******\locals~1\temp\is-228l1.tmp\is-g7pn3.tmp" was allowed to run
[EXECUTION] Started by "c:\documents and settings\******\desktop\ak_setup.exe" [192]
[EXECUTION] Commandline - [ c:\docume~1\******\locals~1\temp\is-228l1.tmp\is-g7pn3.tmp /sl4 $e02c6 "c:\documents and settings\******\desktop\ak_setup.exe" 1365338 68096 ]

Sat 16 - 23:33:39 [EXECUTION] "c:\docume~1\******\locals~1\temp\is-gmm8r.tmp\regser.exe" was allowed to run
[EXECUTION] Started by "c:\docume~1\******\locals~1\temp\is-228l1.tmp\is-g7pn3.tmp" [204]
[EXECUTION] Commandline - [ "c:\docume~1\******\locals~1\temp\is-gmm8r.tmp\regser.exe" "1" ]

Sat 16 - 23:33:53 [EXECUTION] "c:\documents and settings\******\desktop\ak_setup.exe" was allowed to run
[EXECUTION] Started by "c:\windows\explorer.exe" [500]
[EXECUTION] Commandline - [ "c:\documents and settings\******\desktop\ak_setup.exe" ]

Sat 16 - 23:33:53 [EXECUTION] "c:\docume~1\******\locals~1\temp\is-20r9v.tmp\is-csv1b.tmp" was allowed to run
[EXECUTION] Started by "c:\documents and settings\******\desktop\ak_setup.exe" [268]
[EXECUTION] Commandline - [ c:\docume~1\******\locals~1\temp\is-20r9v.tmp\is-csv1b.tmp /sl4 $1002c6 "c:\documents and settings\******\desktop\ak_setup.exe" 1365338 68096 ]

Sat 16 - 23:34:02 [EXECUTION] "c:\docume~1\******\locals~1\temp\is-2asq7.tmp\regser.exe" was allowed to run
[EXECUTION] Started by "c:\docume~1\******\locals~1\temp\is-20r9v.tmp\is-csv1b.tmp" [240]
[EXECUTION] Commandline - [ "c:\docume~1\******\locals~1\temp\is-2asq7.tmp\regser.exe" "1" ]

Sat 16 - 23:34:27 [EXECUTION] "c:\docume~1\******\locals~1\temp\is-2asq7.tmp\regser.exe" was allowed to run
[EXECUTION] Started by "c:\docume~1\******\locals~1\temp\is-20r9v.tmp\is-csv1b.tmp" [240]
[EXECUTION] Commandline - [ "c:\docume~1\******\locals~1\temp\is-2asq7.tmp\regser.exe" 2 "c:\program files\anti-keylogger\anti-keylogger.exe" ]

If you deny \regserv.exe with PG at any point during the install, you will receive an error message that the install failed. If you allow all with PG, a driver called scrambler.sys is installed via:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\scrambler]

An autostart value for the GUI, anti-keylogger.exe, is also created via:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run "Anti-keylogger 6.0.1"
Data: C:\Program Files\Anti-keylogger\Anti-keylogger.exe /autorun

When you reboot, PG prompts you that anti-keylogger.exe is trying execute. If you deny, it will not execute. If you permit it to execute, the GUI will start minimized to the tray and you will see a splash screen. When I set PG to deny always, anti-keylogger.exe never executed on subsequent reboots. Of course, the driver/service (scrambler.sys) will always load because permission was granted for it to be installed. I did not have a keylogger to test whether or not the driver protected independently of the GUI (as do PG and RD).

While I found that PG works as advertised in relation to the Anti-keylogger executable, two points are worth mentioning:

The first is that the Anti-keylogger installer requires Data Execution Protection to be disabled. If DEP is enabled, the installer terminates with a warning that includes a link to Physical Address Extension - PAE Memory and Windows.

The second is that anti-keylogger.exe, while running (minimized or maximized) is not visible in Task Manager and Process Explorer. It is only visible using Kernel PS or KProcCheck (or other similar specialized apps) and is shown as a hidden process. It was only by using these apps that I was able determine that PG was effective in stopping Anti-keylogger from executing.

Nick

 

Interesting, nick.

I'm still waiting to see if Casper1 comes back and tries the two things suggested to him.

It was pretty much a given that PG was going to get all that info - and work correctly - with a system that had a subsequent install of AKL. Nice to have it so well-documented, though!

It was the system that had AKL on it prior to the PG install that I was hoping to see the log results for from the time PG was installed, onward.

It seems to me that that would be the perfect example of the fallacy of anyone relying on PG (or the like) to protect their computer if they weren't absolutely sure their computer was clean prior to PG's installation. (AKL can stand for an example of both good and bad programs for this).

Or, controler could probably do it if his other computer (the one that doesn't have PG on it yet) does already have AKL on it (that's the state I was wanting to look at - pre-existing "whatever" before the PG installation). Pete

 

Hi Pete,

Unless controller gets to it frst, I will set that scenario up tonight.

Nick

 

I am the lake this weekend fishing and stuff
I will be here till tomorrow night.
And of course, my laptop is what I have with. It has PG but not AKL installed.
I think we have allready decide that PG has to be installed right after Windows & current updates.

I wanted to try out VMwear but I get an error witht hat too. Says I have
the wrong OS lol
I don't know how much better VMwear running on RAMDisk is then shadowuser, but I can tell you it costs a heck of alot more.
If I am correct, shadowuser is another virtual machine.
I still think the best way to detect rootkits is by running another instance of windows on RAM and comparing the online off line results. Now all we need is someone to code the dang thing cheaply

 

A few months back Kevin (BoClean) looked into Anti-Keylogger when I was seeing some issues & so far all those I have contacted seem to say the same thing. Anti-Keyloggers uses some Hacker technologies. Although untill now didn't mention rootkits.

Bruce

 

I don't know if we will ever see Kevin, Dmirty & Raytown, DCS here on the same thread but I would hope they still work together behind the scenes.
From what I undestand, who ever gets to ring0 first on boot wins.
I think AKL was one of the first programs I ever saw that started it's driver
before user logged on. Now we are seeing almost all the security apps doing this.


Bruce

 

Went ahead and installed PG with Anti-keylogger already present. PG, in Learning Mode, catches and permits anti-keylogger.exe execution and then adds it to the Protection List with default permissions:

Sun 17 - 13:49:43 [EXECUTION] "c:\program files\anti-keylogger\anti-keylogger.exe" was allowed to run
[EXECUTION] Started by "c:\windows\explorer.exe" [296]
[EXECUTION] Commandline - [ "c:\program files\anti-keylogger\anti-keylogger.exe" /autorun ]

After exiting Learning Mode, PG permits and logs anti-keylogger.exe executing:

Sun 17 - 14:00:00 [EXECUTION] "c:\program files\anti-keylogger\anti-keylogger.exe" was allowed to run
[EXECUTION] Started by "c:\windows\explorer.exe" [1000]
[EXECUTION] Commandline - [ "c:\program files\anti-keylogger\anti-keylogger.exe" /autorun ]

After setting PG to always deny anti-keylogger.exe, then reboot, both the PG alert window and the raw logs show its execution blocked:

Sun 17 - 14:15:21 [EXECUTION] "c:\program files\anti-keylogger\anti-keylogger.exe" was blocked from running
[EXECUTION] Started by "c:\windows\explorer.exe" [1000]
[EXECUTION] Commandline - [ "c:\program files\anti-keylogger\anti-keylogger.exe" /autorun ]

Using KProcCheck, I did not see the normally hidden Anti-keylogger process running.

Nick