13 gateways to get into your PC

[jj2007]

Here is a handy list showing a dozen ways to plant malware in your PC. Champagne to our friends in Redmond!


Run key (machine) Programs listed in the registry’s HKLM\Software\Microsoft\Windows\CurrentVersion\Run key are available at startup to all users.


Run key (user) Programs listed in the HKCU\Software\Microsoft\Windows\CurrentVersion\Run key run when the current user logs on. A similar subkey, HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\Run, can also be used.


Load value Programs listed in the Load value of the registry key HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows run when any user logs on.


Scheduled tasks The Windows task scheduler (see “Using the Windows 7 Task Scheduler” on page 779) can specify tasks that run at startup. In addition, an administrator can set up tasks for your computer to run at startup that are not available for you to change or delete.


Win.ini Programs written for 16-bit Windows versions can add commands to the Load= and Run= lines in the [Windows] section of this startup file, which is located in %SystemRoot%. The Win.ini file is a legacy of the Windows 3.1 era.


RunOnce and RunOnceEx keys This group of registry keys identifies programs that run only once, at startup. These keys can be assigned to a specific user account or to the machine:
HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce
HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnceEx
HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce
HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnceEx


RunServices and RunServicesOnce keys As the names suggest, these rarely used keys can control automatic startup of services. They can be assigned to a specific user account or to a computer.


Winlogon key The Winlogon key controls actions that occur when you log on to a computer running Windows 7. Most of these actions are under the control of the operating system, but you can also add custom actions here. The “HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit” and “HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell” subkeys can automatically launch programs.


Group Policy The Group Policy console includes two policies (one in Computer Configuration\Administrative Templates\System\Logon, and one in the comparable User Configuration folder) called Run These Programs At User Logon that specify a list of programs to be run whenever any user logs on.


Policies\Explorer\Run keys Using policy settings to specify startup programs, as described in the previous paragraph, creates corresponding values in either of two registry keys: HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run or HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run.


BootExecute value By default, the multistring BootExecute value of the registry key HKLM\System\CurrentControlSet\Control\Session Manager is set to autocheck autochk *. This value causes Windows, at startup, to check the file-system integrity of your hard disks if your system has been shut down abnormally. It is possible for other programs or processes to add themselves to this registry value. (Note: Microsoft warns against deleting the default BootExecute value.


Shell service objects Windows loads a number of helper dynamic-link libraries (DLLs) to add capabilities to the Windows

[Gunther]

Jochen,

thank you for the interesting list. It'll be a lot of work toc check all points.

Gunther

[sinsi]

A lot of those (e.g. HKLM) need admin access, if you disable UAC then you get what you deserve 
Lots of malware can be removed easily by using another account to log on.

[GoneFishing]

Hi Jochen!

Thank you for very useful post!
I think soon we'll see " Another 13 gateways ... "  ;) 
BTW what do you think about "Log on script" setting? Is it unsafe too?
 

[dedndave]

i didn't see these mentioned...

C:\Documents and Settings\[UserName]\Start Menu\Programs\Startup
C:\Documents and Settings\All Users\Start Menu\Programs\Startup

C:\Windows\System32\Autoexec.nt
C:\Windows\System32\Config.nt

browser add-ins/bho's
not applied at start-up, but as soon as you open a browser   :P

[GoneFishing]

Dennis Huges, FBI :

"The only secure computer is one that's unplugged, locked in a safe,
and buried 20 feet under the ground in a secret location... and I'm
not even too sure about that one"

[mywan]

Another method not mentioned is in System.ini. You can modify or add the line:

System.ini: shell=Explorer.exe

To keep the Explorer shell you can simply append another executable after Explorer.exe. Haven't tested it on later versions of windows but should still work given the fundamentals. There should also be a way to accomplish the same thing in the registry, especially on later versions of windows.

[Antariy]

I'll second John's suggestion: work under limited user account (or even guest). If one sometimes needs admin rigts - the impersonation is a way to go ("Run as..." or runas.exe command) - just run the program that really, and only requires admin rights, do the job and terminate it. Any program that was executed by that program will inherit admin rights, so, having a simple file manager running in admin rights, one potentially can do anything he wants even if currently working under limited user account. One can also disable the impersonation having the "Secondary logon" service disabled.

And, of course, setup the good passwords for the every account on the machine - otherwise working under limited user account has no reason - malware may launch impersonated program with admin rights if admin pass is empty or simple, and if this - empty pass + impersonation - is allowed in Local Security Settings (secpol.msc -> Local Policies -> Security Options -> parameter "Accounts: Limit local account use of blank passwords to console logon only" should be "Enabled" to disallow impersonation if password is empty).

[Zen]

JOCHEN,   
Useful intel,...thanks.
Tell me if I'm wrong about this (my knowledge of Windows security is severely limited),...but, doesn't the evildoer (malware writer) have to somehow get some executable code loaded into memory on the victim's computer first before any of the registry settngs would take effect ???
...Or, is this such a trivial activity that it's not worth even attempting to prohibit ???

[jj2007]

Zen,
I am not a Windows security expert either, but it seems malware writers like the RunOnce registry entries a lot. Getting inside during the boot phase, if possible before the AV installs itself, makes things a lot easier...

[Antariy]

You can "disable" all those "Run" and "RunOnce" keys even for user account. Note: when these keys are "disabled", many programs will fail in attempts to add themselves into "Run %put_the_program_name_here% at startup" mode - i.e. this option, if exists, won't work in the programs. Also some installations require "Run" or "RunOnce" keys for completion the installs (after a reboot).

To "disable" the key you want (this method works not only for keys described here, but may be used for every key you want to limit the access to), run the registry editor in the admin mode, but with using current user profile, in the command line (WinXP):

runas.exe /noprofile /user:Administrator regedit.exe

(change Administrator to actual admin's login)

Find the key: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
click on it with right mouse button, select "Permissions...".

There click "Advanced" button, in the opened dialogue uncheck the checkbox starting with words "Inherit from parent ...", in the next dialogue that will appear, click "Remove" button. Then, in the dialog you're just unchecked "Inherit ..." checkbox, click "Add..." button - and this way you can step-by-step set the user rights up - for example, allow "Administrator" and "System" user to have full access of the key, or you can just enter "Everyone" as a login, and in the next dialogue, select these checkboxes to the state "Allow": "Query value", "Enumerate subkeys", "Notify", "Read control" (you can do the same in the first dialogue that shows after selecting "Permissions..." menu item in the key context menu, just by selection "Read" permissions as allowed, and clearing all other checkboxes - do this for every user you want limit the access as a read only).

You can set up rights this way for every "standard" potentially dangerous key.

So, being working under limited user account, with properly set up access rights for the registry and file system (actually, all system files are already read-only for the user account), you can make it to be protected from using standard ways as malicious. Though, there is no way to protect from system security holes, like, if possible, rights elevation using bugs of the system. But those holes have tendency to be closed - being once used. The standard ways - standard system functions like "Run" etc are - shotly speaking, may be closed only by user, because those are functions that were designed to run that way, just like "DeleteFile" API may be used to delete a garbage temporary file, and to delete important user's document as well.

And, one more note: "Windows NT" - is not the system that was initially designed to be used on the workstations, and we can see many roots of this these days, still. Administrator account - as we know it these days - was not designed to be used for everyday-work either - just by "system design". Unix/Linux users are well known for their dislike to work under the "root" account (it's like Administrator in Windows), but this habit is rare in the Windows sphere. But working under the "User" account rights - even without any additional settings changement, the Windows user will massively decrease the paths that malware may use.

Having another system installed on your machine, you may backup the entire registry.
Find in the registry editor this key.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\hivelist
The values in it are containing the full paths to every file of the registy - save the list somewhere, then boot from other system, the save the files listed, and then, after some experiment, or software setup, or hardware settings changement, or malware activity (after it will be removed), or many other things that make your system unstable, you can just restore all those saved files to their original places (don't entangle something! and back up old files somewhere, too), and this action will return registry to the state it has at the time you made that backup with saved files.

All described here may be used only for your own risk (though, they are a pretty proper and "legal" things to do), not claims to be full, and was specifically for English WinXP (more or less for 2000, too, as well as 2003), but it may be suitable for more modern systems as well - it will be very interesting to hear John's thoughts on this, as he has experiencies with modern systems, and system-repairing things are very familar for him

[sinsi]

Users still need access to anything under HKCU, since they "own" it, so I would disagree with setting permissions.
Anyone running at least Vista should make a limited user account just to see how security is supposed to work.
Having to type in a password is a lot different to clicking "yes".

Vista onward has an Administrator account but it is disabled by default. This account has no UAC, everything runs at the top level of access.
It's the one I activate to clean up malware* since it's usually a user infection. Like I said, their problem.
XP has an Administrator account but it usually isn't visible without safe mode, and possibly only Pro.


*I would like to know the vector for rootkits, especially 0access/aleurion. They are Windows killers, all you can do is format and reinstall.

[Antariy]

Users still need access to anything under HKCU, since they "own" it, so I would disagree with setting permissions.

I don't know how it works on Vista and onwards, but on the systems earlier you can set up rights for every user in that way so it will be unable to change the rights and/or change anything in the "protected" key/subkeys if the rights disallow this. The main point: it is better to completely remove that user from the permission list, as well as remove all inheritance (this was described in previous post), then add every user required to have access to the key, and assign the rights manually. For example, for the system/admin it may be full access, but for the "creator-owner" it may be other.

BUT, the one thing that is wrong in my previous post (completely forget abou it :( ): running regedit with runas with /noprofile switch doesn't run regedit with the current user profile. It runs it with "default" profile. So, running the regedit as an Admin there is need to to locate the user's profile in the HKEY_USERS hive - it will be something like HKEY_USERS\S-1-2-34-5678901345-6789012345-012345678-9012\Software\Microsoft\Windows\CurrentVersion\Run key, and setup the rights there - if regedit runned from an admin account. But the user from its own account may once also setup the rights for the key to be read only - in the permissions for its account need just clear all checkboxes other than "Read", and after this user will be unable to change anything in the key - even permissions.

I don't know what you meant - maybe file permissions (which has the owner), but for the registry this really works (well, to prove it I it is enough to say that it is how it is set up in my system right now - and there is no program that able to edit protected key in any standard way) - rights maybe assigned absolutely flexible for every user, it is possible even to delete all users from access, so only the admin will be able to return the access. So, having changed the rights for non-admin user to read only - even if this setting is doing right under non-admin user - for those user there will be no way to return any other access right as well as user (programs runned by this user) will be unable to make any changes in the key/subkeys.


(Yes, I told about XP Pro, but you should be able to logon into admin under Home not only in safe mode, but, for an instance, pressing Ctrl+Alt+Del while logon screen)

[Antariy]

Users still need access to anything under HKCU, since they "own" it, so I would disagree with setting permissions.

Probably now I get: you thought I told about entire HKCU key, but I meant to setup the rights only for specific keys - like "Run" is. This way user will has the same access to registry, except the keys he wants to be protected.

Sorry if it was explained unclearly (still Cyrillic English )