Search This Blog

Thursday, September 28, 2017

Microsoft is breaking our security improvements with the new Windows 10 cumulative updates/upgrades

Windows 10 has been touted as a more secure Windows.  With Windows 10, Microsoft has changed the way systems are patched.  No more ‘Patch Tuesday’ with a bunch of miscellaneous files or individual patch items numbering in the tens.  Microsoft is now rolling up the patches into an actual Operating System upgrade referred to as “Windows 10 cumulative updates”.  Some see this as a good thing, but it actually breaks settings many of us security people apply, or are recommending people apply, or worse have applied and are now removed due to the upgrade(s).

Before continuing I think it is important to state that I do not feel the default configuration of Windows is at all secure enough for today’s security threats.  It is not secure enough for home users, pro users, education users, or enterprise users.  Microsoft is implementing many new security features with Windows 10, but completely failing at basic ‘Security 101’.  Some can argue that compliance and standards address this by telling you what to set using Group Policy (GPO), but not everyone, nor does every system have Group Policy as an option.  Home users (You, Mom & Dad, Kids, friends, etc.), Small and Medium Businesses (SMB’s), educational institutions, kiosks, labs, and many other systems purposefully do not use Group Policy.  Expecting "Group Policy is the only way to control or apply basic security settings" is a flawed way of thinking in today’s security eco-system.

Without GPO forcing settings to each system, it is left to the system admin(s) or consultants to manually configure the system, or create a ‘gold image’ that has many of these settings built-in to the image that is being deployed.  Many security hardening standards such as: the Center for Security (CIS) Benchmarks, US GCB’s, or our own ‘Windows Logging Cheat Sheets’ are meant to improve the basic security of a Windows system that is crucial for systems built today, or tomorrow.

So what kind of things do us InfoSec people recommend and set to improve Windows security?  Here is a list of a few things:
  1. Improved logging by setting over 50 items that are NOT set by default EVER
  2. Increased log sizes in order to collect more than a few minutes or hours of logs, the goal is a week or longer
  3. Enabling logs that are NEVER enabled by default, but crucial to catching malicious behavior
  4. Change default file associations that are regularly used to infect systems due to insecure default configurations
  5. Enable auditing of key directories to monitor for new or deleted files

Logging is important as it tells us what happens and how so we can fix or clean up an infection, and hopefully learn how the whole event happened to begin with.  The goal, to hopefully avoid it from happening again.  In order to gather this data, one must first enable the logging to collect that which we Incident Responders and Forensics people would want and need.  Even if it is Mom and Dad, your Chiropractor, SMB’s, even corporate users need these settings and Group Policy is often not available to set and push them.

File associations are, have been, and will be a major way users are so easily infected with malware and ransomware.  Why?  Because of the terrible default configuration that has left this vulnerability unaddressed since Windows 3.1.  The malwarians know about these default configurations and with the recent WannaCry and Not Petya ransomware attacks, the malwarians continue to take advantage of these default file associations to infect systems.  Windows users, system administrators, and even many InfoSec Professionals still have no clue how easily malware and ransomware can be significantly reduced, if not almost eliminated by changing a few file associations.

Now back to HOW Microsoft is breaking security of Windows 10 with their cumulative updates.

When Microsoft applies one of their new “cumulative updates” they apply a security policy to the system at the end of the upgrade.  So why is this an issue?    

If you alter any of the following items the settings are reset to the grossly inadequate Windows default:
  1. Log sizes are reset to 20,480kb, sadly inadequate
  2. The Task Scheduler log and others are disabled if they were enabled
  3. File associations are reset to defaults if they were changed
  4. File auditing set on folders are removed
  5. Data that was in the logs from larger settings is rolled out with reset of log sizes
These are ones I currently know about, there are likely more.  So far there has been three (3) of them since Windows 10 shipped.

Here are some screen shots of the settings AFTER the Patch/Cumulative upgrade:

Application Log Size:
  • Before - 256,000
  • After - 20,480
 Security Log Size:
  • Before - 1,000,000
  • After - 20,480
 System Log Size:
  • Before - 256,000
  • After - 20,480
 PowerShell/Operational Log Size:
  • Before - 500,000
  • After - 15,360

Windows PowerShell Log Size:
  • Before - 500,000
  • After - 15,360

TaskScheduler Log:
  • Before - Enabled
  • After - Disabled

What the C:\Users Folder Auditing was BEFORE the upgrade:
  • Everyone for adds and deletes

Folder Auditing of C:\Users\<username>\Local
  • Before - Everyone for adds and deletes
  • After - nothing

Folder Auditing of C:\Users\<username>\Local
  • Before - Everyone for adds and deletes
  • After - nothing

File Associations:

  • Before - Set to Notepad.exe

  • After - Set to default script engine

So what are the ramifications of these changes?

While investigating an incident, I tried to use LOG-MD to harvest the log data and discovered this issue.  I am REALLY glad we built this audit logic into LOG-MD by design!  Maybe we should call this feature the “Post Windows 10 Update Security Settings Validation Tool”.  Unfortunately LOG-MD is designed not to collect log data unless the system is compliant to the settings in the ‘Windows Logging Cheat Sheet’.  

The data we all want and need was in the log before the “cumulative update”.  After the “cumulative update” was applied, the data that was there the day before was rotated out!  In addition it was discovered folders being audited to collect file drops malware created were no longer set and events being collected.  Also significant was the File Associations that were altered to prevent several malicious file types from executing when clicked on by the user were reset to once again execute the script engine defaults.

If this were my chiropractor that accidentally clicked a .js file, it would have detonated the malicious payload.  If I were to open the logs and look at what happened, it would have been gone before I arrived on-site.  I present a “How to avoid Ransomware” talk at many security conferences to educate people on the risks and how to reduce it, while providing more log data when an investigation is warranted.  

Testing these security improvements in our malware lab clearly showed these log, file association and audit settings are crucial to reducing risk from a user clicking the wrong file type and having access to the data in the logs that could explain what happened, and hopefully remediate the system back to a normal state quickly.

I have provided this information to Microsoft in hopes that they research, investigate and address this issue to stop this weakening of security following a patch cycle that is theoretically supposed to increase security.  Hopefully they will address the issue and fix this terribly insecure oversight.

Because of this ill side-effect, I have provided a script that will set these items to their recommended desired state and settings from the ‘Windows Logging Cheat Sheet’ that you can tweak to your needs.  The script will set the following file associations to open Notepad versus the default script engine that will detonate malicious payload if a user double-clicks a malicious email attachment:
  • .js, .jse, .wsf, .wsh, .vbe, .vbs, .hta, .pif
The log sizes are set to the following:
  • Application and System – 256,000kb
  • Security – 1,000,000kb
  • Windows PowerShell – 500,000kb
  • PowerShell/Operational – 500,000kb
The following log is enabled:
  • TaskScheduler
Optionally, the following folder auditing can be enabled if you choose, follow the 'Windows File Auditing Cheat Sheet' on what you should audit by default:
  • C:\Users\<username>\AppData\Local
  • C:\Users\<username>\AppData\Roaming
  • C:\Users\Public
The script can be scheduled to run when a user logs in, every 15 minutes, or added to the users Startup folder, but the user must be an administrator to alter the log settings, and why scheduling a task would be the best option as that will run with elevated rights.

You can find the script on the website:
You can find several cheat sheets for Windows logging on the website as well:

And the tool we discovered this issue with, LOG-MD is found here: