Hello everyone.
In this thread I will be discussing a small bit about some of the most important but sometimes underrated Windows protection features which are built-into the OS (at least by Windows 10) - of course I cannot fill every gap to write about but if anyone has additional content to share to help extend this thread then feel free to post it as a reply to this thread.
Part 1 – User Account Control
User Account Control is a very important feature which has been integrated into Windows since Windows Vista and on-wards, and over the past Windows editions it has been significantly improved. There used to be many methods of exploiting it, however due to all the research from security researchers and vulnerabilities found in total, Microsoft have worked very hard to patch these up and make UAC as secure as they can – it’s much more stable and secure than it used to be to say at the very least, and it does the job well.
There is a big misconception with User Account Control amongst tons of Windows users, and that is about how UAC is “bad” or “doesn’t work very well” because the user ended up becoming infected. Sometimes, a Windows user will disable UAC entirely, and still complain about how it is useless because they got infected, even though it wasn’t even enabled! Over the past few years I’ve seen the complaints reduce down more and more, with the start on Windows Vista causing a blow of complaints to seeing a big reduce since Windows 10, however I still see people leaving it disabled or complaining about how useless it is, even though it is a very good and important feature as long as it’s used correctly and responsibly.
The purpose of User Account Control is NOT to leave your system invincible to malicious software, but to allow you to control which programs can do more than others – by this I am talking about programs with standard rights (not running as administrator) being limited in the changes they can make to your system, and programs which have administrator rights (running as administrator) which allows them to make more changes to your system.
When you run a program it should run with standard rights, however some software will enforce administrator privileges so it can run via usage of the manifest file. The manifest file is similar to a configuration file; you can set a value to a variable which will cause Windows to add the administrator icon to the program executable icon (at the bottom left), and enforce the UAC prompt as long as UAC is enabled on the system before it can be executed – this doesn’t mean you should automatically allow, but only run the program if you trust it and want to give it additional rights to your system.
When a program is running with administrator privileges it can make many more modifications to your system, and if you grant a program to run as administrator then it won’t require any additional prompts to make these changes – in some situations a program will run with standard rights but Windows will prompt you so it can make some changes to your system without it needing to be restarted with administrator privileges entirely.
When a program is running with elevated privileges (as Administrator) it allows it to do the following (of course the following list is not complete but will only outline some of the things a program running as admin can do which a standard-rights program cannot do):
As well as this, if you allow a program to run with administrative privileges, it will give it access to other programs which are running as administrator, which means it will obtain the ability to open a handle to the other running processes and inject code into them, allowing the program to compromise all other running programs (e.g. a program running with standard rights cannot inject into a program running with higher-up privileges, whereas a program running as administrator will be able to inject into all standard-running programs but also all other programs running with administrative rights).
If you are on a standard rights account on Windows and you are not running on an administrative account then you will be required to enter the password to an administrator account to run programs as admin – this is an additional layer of security since it makes it harder to bypass the UAC protection mechanisms, especially if you are infected with a backdoor and the attacker wants to run a program as admin remotely, but does not know the password to an admin account on the system.
Part 2 – SmartScreen
SmartScreen is an exceptionally good feature which was integrated system-wide into Windows by default starting from Windows 8. Before Windows 8, it was a security mechanism integrated into Internet Explorer only, however it has been evolved into system-wide protection – it can be disabled by the user however this is definitely not advised since it can be very effective in terms of keeping your system secure, just like User Account Control, if used responsibly.
The way the system-wide SmartScreen will work is when you run a program which is unknown/untrusted you will be presented with a big alert from Windows notifying you that the program execution was automatically blocked since the program was ‘unrecognized’ and that by allowing the program you could leave your system at risk – SmartScreen gets the point across and anyone who thinks twice will accept the alert and not run the program before performing additional check-ups (say on case it was a false positive detection), although some few individuals will ignore all of these alerts, allow the execution and then complain about Windows security and how it is so bad when they become infected (funny, right?).
SmartScreen will use multiple factors during its determination of whether it should auto-block execution of a program or not. An example of one of these factors would be digital signatures – for example, is the program you are attempting to execute digitally signed/signed by a Trusted Publisher? Microsoft (in some/or most cases) will also perform cloud check-ups (assuming there is an active internet connection on your system at the time) with the program you are attempting to run and will show the alert based on the results returned from the cloud queries on their server-side – they can use this to store trusted applications/publishers in the cloud, and they can also work with reputation popularity when deciding whether to block a program or not (e.g. if few people running Windows 8 or higher are using the program then it may be blocked, whereas if you are trying to run a program which is very well-known and popular amongst users of Windows from Windows 8 and on-wards, chances are it’ll be allowed and not blocked).
Overall, SmartScreen is a great security feature if used correctly – make sure you pay attention to the alerts and not automatically go on auto-pilot mode and allow things for the sake of it, because being click-happy this way will probably lead you into a trap of a malware infection… Better be safe than sorry, and if you are trying to run a program which becomes blocked by SmartScreen, start doing your research and make sure it is safe before you blatantly allow it to run on your system, especially if you were trying to run it with administrative privileges!
Part 3 – PatchGuard (PG)/Kernel Patch Protection (KPP)
PatchGuard and Kernel Patch Protection are very important protection mechanisms built-into Windows since Windows Vista. If you only want a brief description of what these features do then they are essentially there to help keep the Windows Kernel better protected against manipulation, thus keeping it more stable. However, PatchGuard and Kernel Patch Protection are only for x64 versions of Windows (from Vista and on-wards), therefore you will not have the limitations on x86 systems.
Microsoft noticed that back in the Windows 2000/XP days people were reverse engineering the Windows Kernel and finding out secrets and discovering how it works, and this started allowing people to manipulate the kernel through various patching methods (e.g. System Service Dispatch Table Hooking, Direct Kernel Object Manipulation) and they did not like this at all – they didn’t want people performing these manipulations because it was being abused by malware authors too much (e.g. for rootkit development) and was potentially causing an impact on system performance and stability depending on how it was done. However, Microsoft knew at this time that a lot of software was heavily reliant on these techniques for its functionality (e.g. back in the day the security software would be using SSDT hooks as a method of monitoring process creation, and also as part of any dynamic behavioural protection features which may have been existent back then, such as preventing drivers from being loaded via hooking functions like NtLoadDriver). Since Microsoft did not like people performing modifications like this to the Windows Kernel, they decided to introduce Kernel Patch Protection to prevent this – patching methods such as SSDT hooking and DKOM are now prevented.
PatchGuard works with Kernel Patch Protection, however its main purpose is to prevent the loading of rogue device drivers – it does this by preventing any unsigned device drivers from being loaded on the system. If you attempt to load a device driver which is not digitally signed, it will simply fail. In the past, people have managed to bypass PatchGuard through loading the device drivers (which are unsigned) before Windows even initialises PatchGuard up, however Microsoft did patch these vulnerabilities up. An example of some old malicious software which sky-rocketed the security industry would have been Carberp, the banking Trojan, which included PatchGuard-bypassing functionality.
Due to PatchGuard/Kernel Patch Protection only being present on x64 versions of Windows, it does make Windows x64 much more secure than Windows x86, simply because there are more protection mechanisms put into place. On x86 systems, if an attacker can gain code execution onto your system and they have the correct privileges to load a device driver (SeLoadDriverPrivilege - acquired if the program is running with administrative privileges) then they can easily load an unsigned device driver (non-digitally signed) and then afterwards they can control what software can and cannot do through the use of kernel-mode patching (which means the malicious rogue driver can prevent programs such as Task Manager from listing specific processes and/or being able to terminate other malicious processes, hide/prevent removal of files and registry keys, and so on – this is why kernel-mode rootkits can be very powerful and tricky to rid of due to the control they have).
That being said, you can still be protected from rogue drivers on x86 systems if you are working with security software which includes a good Behaviour Blocker/Host Intrusion Prevention System – some will support preventing new device driver/service installations without user authorisation, which means you would have to manually provide consent either through whitelisting the program or via the alert). Of course, this is not going to be as full-proof as the built-in PatchGuard protection on x64 versions of Windows and of course this will not prevent drivers which do become loaded from performing kernel-mode patching techniques, but it’s a start and still an additional layer of protection (via dynamic analysis and prevention methods). As for preventing kernel-mode patching on x86 systems, there will be some software out there which will perform scans in kernel-mode to identify DKOM usage/SSDT hooks, and will then support repairing of these actions (e.g. anti-rootkit scanners should pick these up, even if it wasn’t done by a rootkit itself). Of course, if real malicious software has kernel-mode execution on x86 then they can conceal the evidence of this and prevent external third-party scanning tools from even successfully executing… So it is a tricky game once you become infected, therefore most people just resort to formatting, reinstalling the OS and then using backed up data (which is clean and made prior to infection) to restore their personal documents.
The best thing to do is to not grant any untrusted programs administrator privileges, which removes the chance of them from loading a device driver which can cause harm to the system in any way without first exploiting the system to obtain higher privileges to do so; and this is easier said than done and quite rare these days, and these sorts of exploits cost a lot of money for someone to purchase, and most people cannot even develop them themselves since it takes a lot of experience and knowledge on the windows internals to do these sorts of things.
-------------------------------------------
Hopefully someone found this thread useful; I have previously written a thread on User Account Control, if you'd like to read it you can find it here: Why UAC should be taken seriously
Stay safe,
Wave.
In this thread I will be discussing a small bit about some of the most important but sometimes underrated Windows protection features which are built-into the OS (at least by Windows 10) - of course I cannot fill every gap to write about but if anyone has additional content to share to help extend this thread then feel free to post it as a reply to this thread.
Part 1 – User Account Control
User Account Control is a very important feature which has been integrated into Windows since Windows Vista and on-wards, and over the past Windows editions it has been significantly improved. There used to be many methods of exploiting it, however due to all the research from security researchers and vulnerabilities found in total, Microsoft have worked very hard to patch these up and make UAC as secure as they can – it’s much more stable and secure than it used to be to say at the very least, and it does the job well.
There is a big misconception with User Account Control amongst tons of Windows users, and that is about how UAC is “bad” or “doesn’t work very well” because the user ended up becoming infected. Sometimes, a Windows user will disable UAC entirely, and still complain about how it is useless because they got infected, even though it wasn’t even enabled! Over the past few years I’ve seen the complaints reduce down more and more, with the start on Windows Vista causing a blow of complaints to seeing a big reduce since Windows 10, however I still see people leaving it disabled or complaining about how useless it is, even though it is a very good and important feature as long as it’s used correctly and responsibly.
The purpose of User Account Control is NOT to leave your system invincible to malicious software, but to allow you to control which programs can do more than others – by this I am talking about programs with standard rights (not running as administrator) being limited in the changes they can make to your system, and programs which have administrator rights (running as administrator) which allows them to make more changes to your system.
When you run a program it should run with standard rights, however some software will enforce administrator privileges so it can run via usage of the manifest file. The manifest file is similar to a configuration file; you can set a value to a variable which will cause Windows to add the administrator icon to the program executable icon (at the bottom left), and enforce the UAC prompt as long as UAC is enabled on the system before it can be executed – this doesn’t mean you should automatically allow, but only run the program if you trust it and want to give it additional rights to your system.
When a program is running with administrator privileges it can make many more modifications to your system, and if you grant a program to run as administrator then it won’t require any additional prompts to make these changes – in some situations a program will run with standard rights but Windows will prompt you so it can make some changes to your system without it needing to be restarted with administrator privileges entirely.
When a program is running with elevated privileges (as Administrator) it allows it to do the following (of course the following list is not complete but will only outline some of the things a program running as admin can do which a standard-rights program cannot do):
- Perform modifications with the Task Scheduler.
- Perform modifications relating to creating Windows Services/loading device drivers.
- Perform modifications to protected directories (such as: Windows folder; Program Files/Program Files (x86)).
- Perform modifications to the Windows Registry at protected locations (HKEY_LOCAL_MACHINE is a protected area for example, so is the UAC settings (yes, any program running as UAC can actually disable UAC completely), etc).
- Perform modifications to the local system date/time
- Perform modifications for another user on the system
- Perform modifications for Windows Update/SmartScreen/Windows Firewall - (I already mentioned UAC earlier).
As well as this, if you allow a program to run with administrative privileges, it will give it access to other programs which are running as administrator, which means it will obtain the ability to open a handle to the other running processes and inject code into them, allowing the program to compromise all other running programs (e.g. a program running with standard rights cannot inject into a program running with higher-up privileges, whereas a program running as administrator will be able to inject into all standard-running programs but also all other programs running with administrative rights).
If you are on a standard rights account on Windows and you are not running on an administrative account then you will be required to enter the password to an administrator account to run programs as admin – this is an additional layer of security since it makes it harder to bypass the UAC protection mechanisms, especially if you are infected with a backdoor and the attacker wants to run a program as admin remotely, but does not know the password to an admin account on the system.
Part 2 – SmartScreen
SmartScreen is an exceptionally good feature which was integrated system-wide into Windows by default starting from Windows 8. Before Windows 8, it was a security mechanism integrated into Internet Explorer only, however it has been evolved into system-wide protection – it can be disabled by the user however this is definitely not advised since it can be very effective in terms of keeping your system secure, just like User Account Control, if used responsibly.
The way the system-wide SmartScreen will work is when you run a program which is unknown/untrusted you will be presented with a big alert from Windows notifying you that the program execution was automatically blocked since the program was ‘unrecognized’ and that by allowing the program you could leave your system at risk – SmartScreen gets the point across and anyone who thinks twice will accept the alert and not run the program before performing additional check-ups (say on case it was a false positive detection), although some few individuals will ignore all of these alerts, allow the execution and then complain about Windows security and how it is so bad when they become infected (funny, right?).
SmartScreen will use multiple factors during its determination of whether it should auto-block execution of a program or not. An example of one of these factors would be digital signatures – for example, is the program you are attempting to execute digitally signed/signed by a Trusted Publisher? Microsoft (in some/or most cases) will also perform cloud check-ups (assuming there is an active internet connection on your system at the time) with the program you are attempting to run and will show the alert based on the results returned from the cloud queries on their server-side – they can use this to store trusted applications/publishers in the cloud, and they can also work with reputation popularity when deciding whether to block a program or not (e.g. if few people running Windows 8 or higher are using the program then it may be blocked, whereas if you are trying to run a program which is very well-known and popular amongst users of Windows from Windows 8 and on-wards, chances are it’ll be allowed and not blocked).
Overall, SmartScreen is a great security feature if used correctly – make sure you pay attention to the alerts and not automatically go on auto-pilot mode and allow things for the sake of it, because being click-happy this way will probably lead you into a trap of a malware infection… Better be safe than sorry, and if you are trying to run a program which becomes blocked by SmartScreen, start doing your research and make sure it is safe before you blatantly allow it to run on your system, especially if you were trying to run it with administrative privileges!
Part 3 – PatchGuard (PG)/Kernel Patch Protection (KPP)
PatchGuard and Kernel Patch Protection are very important protection mechanisms built-into Windows since Windows Vista. If you only want a brief description of what these features do then they are essentially there to help keep the Windows Kernel better protected against manipulation, thus keeping it more stable. However, PatchGuard and Kernel Patch Protection are only for x64 versions of Windows (from Vista and on-wards), therefore you will not have the limitations on x86 systems.
Microsoft noticed that back in the Windows 2000/XP days people were reverse engineering the Windows Kernel and finding out secrets and discovering how it works, and this started allowing people to manipulate the kernel through various patching methods (e.g. System Service Dispatch Table Hooking, Direct Kernel Object Manipulation) and they did not like this at all – they didn’t want people performing these manipulations because it was being abused by malware authors too much (e.g. for rootkit development) and was potentially causing an impact on system performance and stability depending on how it was done. However, Microsoft knew at this time that a lot of software was heavily reliant on these techniques for its functionality (e.g. back in the day the security software would be using SSDT hooks as a method of monitoring process creation, and also as part of any dynamic behavioural protection features which may have been existent back then, such as preventing drivers from being loaded via hooking functions like NtLoadDriver). Since Microsoft did not like people performing modifications like this to the Windows Kernel, they decided to introduce Kernel Patch Protection to prevent this – patching methods such as SSDT hooking and DKOM are now prevented.
PatchGuard works with Kernel Patch Protection, however its main purpose is to prevent the loading of rogue device drivers – it does this by preventing any unsigned device drivers from being loaded on the system. If you attempt to load a device driver which is not digitally signed, it will simply fail. In the past, people have managed to bypass PatchGuard through loading the device drivers (which are unsigned) before Windows even initialises PatchGuard up, however Microsoft did patch these vulnerabilities up. An example of some old malicious software which sky-rocketed the security industry would have been Carberp, the banking Trojan, which included PatchGuard-bypassing functionality.
Due to PatchGuard/Kernel Patch Protection only being present on x64 versions of Windows, it does make Windows x64 much more secure than Windows x86, simply because there are more protection mechanisms put into place. On x86 systems, if an attacker can gain code execution onto your system and they have the correct privileges to load a device driver (SeLoadDriverPrivilege - acquired if the program is running with administrative privileges) then they can easily load an unsigned device driver (non-digitally signed) and then afterwards they can control what software can and cannot do through the use of kernel-mode patching (which means the malicious rogue driver can prevent programs such as Task Manager from listing specific processes and/or being able to terminate other malicious processes, hide/prevent removal of files and registry keys, and so on – this is why kernel-mode rootkits can be very powerful and tricky to rid of due to the control they have).
That being said, you can still be protected from rogue drivers on x86 systems if you are working with security software which includes a good Behaviour Blocker/Host Intrusion Prevention System – some will support preventing new device driver/service installations without user authorisation, which means you would have to manually provide consent either through whitelisting the program or via the alert). Of course, this is not going to be as full-proof as the built-in PatchGuard protection on x64 versions of Windows and of course this will not prevent drivers which do become loaded from performing kernel-mode patching techniques, but it’s a start and still an additional layer of protection (via dynamic analysis and prevention methods). As for preventing kernel-mode patching on x86 systems, there will be some software out there which will perform scans in kernel-mode to identify DKOM usage/SSDT hooks, and will then support repairing of these actions (e.g. anti-rootkit scanners should pick these up, even if it wasn’t done by a rootkit itself). Of course, if real malicious software has kernel-mode execution on x86 then they can conceal the evidence of this and prevent external third-party scanning tools from even successfully executing… So it is a tricky game once you become infected, therefore most people just resort to formatting, reinstalling the OS and then using backed up data (which is clean and made prior to infection) to restore their personal documents.
The best thing to do is to not grant any untrusted programs administrator privileges, which removes the chance of them from loading a device driver which can cause harm to the system in any way without first exploiting the system to obtain higher privileges to do so; and this is easier said than done and quite rare these days, and these sorts of exploits cost a lot of money for someone to purchase, and most people cannot even develop them themselves since it takes a lot of experience and knowledge on the windows internals to do these sorts of things.
-------------------------------------------
Hopefully someone found this thread useful; I have previously written a thread on User Account Control, if you'd like to read it you can find it here: Why UAC should be taken seriously
Stay safe,
Wave.
