KeyScrambler, is still really effective?

Discussion in 'other anti-malware software' started by ExtremeGamerBR, Nov 12, 2011.

Thread Status:
Not open for further replies.
  1. x942
    Offline

    x942 Registered Member

    This requires some social engineering but:

    Step 1: Mark the file KeyScrambler.exe to be deleted upon reboot.

    Step 2: Reboot the computer.

    This file controls the loading and unloading of KeyScrambler, and provides the tray icon that shows KeyScrambler's status. Windows will delete KeyScrambler.exe when the system is restarted, and KeyScrambler is disabled. Now if you baked this into a trojan, you could automate the process (disguise the trojan as an update to keyscrambler) and have it drop a "fake" keyscrambler that makes it look like the keys are still be scrambled. (The icon in the bottom corner and the window that shows keys "changing")

    EDIT:

    Just found this: https://defuse.ca/softwaresecurity.htm

    Looks like I was beaten to the punch :p
  2. ParadigmShift
    Offline

    ParadigmShift Registered Member

    There are some key words here that bother me, "executed", "run", "edit", "adds", "deletion", "unprotected", etc.

    It turns out, the sky is not falling after all. When it comes to security in Windows, my favorite dialog box is "Access Denied." ;)
  3. Dundertaker
    Offline

    Dundertaker Registered Member

    So does Keyscramble fair....?

    In comparison to OA keylogging effectiveness and that of PrevxSOL..? Any ideas there..?
  4. Hungry Man
    Offline

    Hungry Man Registered Member

    I don't see how any antikeylogger can work if they're "encrypting" keystrokes.

    Instead a keylogger would have to block hotkey calls for individual programs among other things ie: what a HIPS will usually do.
  5. Scoobs72
    Offline

    Scoobs72 Registered Member

    Well, they can work, but the issue is that they seem to be easy to bypass, if malware authors decide they need to bypass them. Take Zeus for example. Its keyboard logging component monitors for key presses and then when it detects one it uses the GetKeyboardState function to retrieve the actual keys pressed.

    Using GetKeyboardState is a very simple key logging method and pretty much any antilogger protects against it. In the case of Keyscrambler, it will protect from Zeus keylogging, because GetKeyboardState will return garbage information to Zeus.

    But a couple of problems emerge:

    1. Zeus or other banking malware could very easily disable Keyscrambler if it wanted to.
    2. Even without disabling Keyscrambler, Zeus still gets the usernames and passwords it wants because it has captured them after decryption (the so called anti-SSL logging element you see in Spyshelter and Zemana), as well as capturing screenshots and clipboard content.

    So Keyscrambler fails against banking malware without the need to disable it. As for Rapport, it would probably protect against the SSL logging and screenshot attacks, but most Rapport installs wouldn't protect against clipboard logging and the keyboard logging protection sounds suspect at best.

    The safest bet appears to be to use an AKL which provides active alerts versus the silent approach of Keyscrambler or Rapport. If you suddenly see alerts for keyboard logging, clipboard logging and screenshot logging you know you have a problem.
  6. Hungry Man
    Offline

    Hungry Man Registered Member

    They protect against legacy malware. Normally I'd say this is fine, there are mitigation techniques in EMET that do the same thing (heapspray, eaf) but TR makes really high claims and it's insanely easy to bypass. I don't think keyscrambler makes the same claims but it's still a pay-product and it's likely just as easily bypassable, but I don't know how it works.

    The silent protections with these two is that they're trying to encrypt keystrokes between you and the program. This is apparently an incredibly flawed idea.

    Blocking actual calls to register key states hotkeys etc is a better way to do this.
  7. carat
    Offline

    carat Guest

    The idea is "great" but I wouldn't execute an unknown file (awesome.exe) ;)
  8. jmonge
    Offline

    jmonge Registered Member

    great.dll:D
  9. x942
    Offline

    x942 Registered Member

    Nope. The sky is not falling. I haven't found any real issues with keyscrambler besides how easy you can disable it. The only issue I can think of is that the encryption key has to be stored in plaintext somewhere. If that becomes known any malware could find it and decrypt any keystrokes. The encryption key also be hardcoded but I doubt it (as it would have been found out by now).

    Just as well as before. Use it for an additional layer of security NOT a sole layer of security. I've found no other issues with it besides being able to kill it so easily. I believe OA can protect user chosen applications from being 'killed' in memory. A hips could be modified to prevent access to the keyscrambler folder from "unknown" programs.

    Exactly. Only an average user (who probably wouldn't be using this) would be at risk. They should still protect those files.
  10. Hungry Man
    Offline

    Hungry Man Registered Member

    If you were to use a Sandboxie profile it would probably pair fairly well with Keyscrambler as long as each profile has blocked read-access to keyscrambler files/folders.

    At that point it might work.
  11. 3x0gR13N
    Offline

    3x0gR13N Registered Member

    To prevent sandboxed apps from deleting/disabling KS outside the sandbox? You don't need to prevent read access as delete=write/modify which, naturally, is isolated by default.
  12. Hungry Man
    Offline

    Hungry Man Registered Member

    To prevent them from reading any keys. Though I guess if the key is loaded up already you'd have to block that too... idk I never spent much time configuring Sandboxie.
  13. 3x0gR13N
    Offline

    3x0gR13N Registered Member

    Ahh I see what you meant to say (I thought you were talking about killing/deleting KS). I'd imagine the encryption key being hardcoded and hard to crack, otherwise it wouldn't be much of a protection if it's plaintext. :)
  14. Hungry Man
    Offline

    Hungry Man Registered Member

    At some point the key has to be in plaintext. When we use something like bitlocker and unlock it the key is stored in RAM.

    IDK enough about it.
  15. x942
    Offline

    x942 Registered Member

    Yes. The key has to be in plain text at some point. They may have store the key in the driver cache, or memory. CPU is possible but unlikely, and if it's part of the executable.. Well game over really. That would mean the is static and everyones key is the same.
  16. Kuffi
    Offline

    Kuffi Registered Member

    I don't know much about hooking; but what prevents a trojan to hook the functions/incoming data before the keyscrambler driver? Why should every trojan hook be installed after keyscrambler in the hookchain? (I assume the trojan might also freely install a driver if it wants to - most people have adminrights/click yes).
  17. carat
    Offline

    carat Guest

    I want to know that too :)
  18. ams963
    Offline

    ams963 Registered Member

    me too ;)
  19. Scoobs72
    Offline

    Scoobs72 Registered Member

    Nothing in theory, but in practice most banking malware hooks after any data would be decrypted by Keyscrambler, so either way Keyscrambler wouldn't protect you. A lot of the banking malware intercepts/hooks all of the following:
    - Keystrokes - Keyscrambler would protect from this
    - Clipboard data - Keyscrambler would fail
    - Screenshots - Keyscrambler would fail
    - 'http/ssl' APIs - Keyscrambler would fail

    1 out of 4 ain't going to protect you unfortunately.
Thread Status:
Not open for further replies.