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:

#HappyHunting


Monday, May 1, 2017

Fileless Malware? Not so fast, let's consider new terms


There is a lot of discussion lately about 'fileless malware', also referred to as 'living off the land', 'memory only', or 'non-malware attacks' .  I do not necessarily agree with this simplistic classification and feel we need to expand what we are calling these attacks to better understand the attack, and thus better detect and defend against them.
Cylance recently put out an article that listed a 'fileless malware attack chain', below is their "Malware Attack Chain" from the article:

Being a defender that spends most of the time performing detection and response duties, I would like to suggest some new concepts to better separate what malware today is doing versus generically calling it 'fileless' which is misleading and does not help us understand the method of the attack, which would also help us detect and defend against them, which is the ultimate goal.

I would like to introduce a new "Malware Archaeology Malware Attack Chain" to incorporate the new proposed concepts.  Let's start with the word malware, which is meant to stand for 'malicious software'.  Let's take this term and modernize it to reflect the evolution of today's malware by aligning it to the ways we would detect and defend against what the malwarians are doing within the attack, whatever type of malware used, which includes the fileless component.

So what do the vendors mean when they say 'fileless malware'?  Well, I think this may vary by vendor and researcher, but generally it is meant to indicate that once a system is fully infected, there are no files remaining on disk that can be found while the system is running and the malware is active.

We should consider that there is more to an infection than the final infected state, because there is!  The stages or ways the system is infected and persists should be the focus to better detect and respond, and perform more focused Incident Response.

Let's take a typical malware infection and walk through the steps or stages of the infection.  We will use a an attack that was received via email, like the above Cylance article used.
  1. Email received and opened
  2. User double clicks an attachment or downloads a file via a URL in the email
  3. The system gets infected executing all the needed steps by downloading any needed files
  4. Executing the malware components
  5. Adding, changing or deleting files
  6. Creating some form of persistence on the system
  7. Running Malware behavior
  8. Re-Infection after a reboot
  9. Re-Infection behavior
  10. Network behavior


Now let's give names to some of these steps so we can define what they are and how they can vary to include a "fileless" type of malware infection.

How about the delivery method, in this case Email.  How about to better know the method of attack delivery something more descriptive like;

  • EmailWare
  • URLWare, or WebWare

Once the download has begun there are many things that happen, starting with the way the infection is delivered, downloaded and initially executed.  How about we call this stage;


  • InfectWare

This would include how the system initially gets infected including the noise made that properly configured logs would capture.  Whether it used built-in utilities, initial executions of binaries, file and registry changes, and everything that can be detected during the initial infection, the logs could capture it.  This can include, as some fileless malware reports mention, the dropping, execution and deletion of files.  Which to me negates the generic term calling it 'fileless', but we will ignore this point for the time being.  This stage I propose it be named "InfectWare".

If files are used, and remain on disk after the infection is complete, we can refer to this stage as;


  • FileWare 

To understand that files are involved at some point during the infection, even if they get deleted after the persistence.  If the files were deleted after the initial infection, we can refer to this as:

  • DeletedWare
Now the persistence can have many names since there are so many ways to persist on a Windows system.  For example; A Simple run key where files remain on disk is a typical malware infection, but we are seeing more methods of persistence with the evolution of malware.  So we need a new way to refer to these infection methods.  There are many forms that are generically referred to as 'fileless malware', so let's give it a better, more descriptive name so we can better focus detection and response.  So let's consider these names to better describe 'fileless malware';

  • RegWare - Malware that hides in the registry
  • WMIWare - Malware that that hides in the WMI database 
  • PSWare - Malware that utilizes PoserShell
  • BootWare - Malware that hides in a systems boot sector
  • Etc...


Now that we have some new terms we can now add clarification to malicious attacks and add much needed context to the "Malware Attack Chain".  Let's add these new terms to the "Malware Archaeology Malware Attack Chain" and we get more information to help us detect and respond and even understand more where to look, and what for.


Now that we have more terms to describe what "fileless" is, fileless malware can be demystified, not as scary, and would be better able to detect and respond to this type of threat using the right tool(s) to hunt for the artifacts.

For example;  LOG-MD-Professional can search the registry for large registry keys, PowerShell Logs, and also locked files which is a new tactic to block binaries from being inspected.  LOG-MD also has an AutoRuns feature that can discover the majority of persistence locations.  Other tools and scripts can focus at WMI persistence or other interesting bits.  Now we at least can get direction at where to look for fileless malware and better improve our detection abilities.

We can also use this logic to evaluation Next Generation Anti-Virus to EndPoint Detection and Response (EDT/EDTR) tools.

Happy Hunting!

PodCast:

References:


#InfoSec #MalwareArchaeology #LOG-MD