Windows security logs monitoring

Security logs collection and analysis is crucial for security incident detection and response. There are many tools that can help in this activity but they can be only as good as the data that is sent to them.

This guide concentrates on providing recommendations and ideas to consider when planning log collection approach for Windows operating system.

System Audit Policy

Windows security events are stored in Security.evtx file. Its contents should be the main focus of Windows OS security logs collection and monitoring. The type of events that are generated on a particular machine is controlled by the System Audit Policy which can be checked on local machine by running the auditpol /get /category:* command. Each category has a set of event IDs associated with it. Below is the list of recommended configuration options together with a list of associated event IDs that can be used as a reference.

Not all noisy events could be excluded as it is not possible to achieve this level of granularity by modifying the System Audit Policy settings. However, they could still be filtered out on the log collection layer.

Continue reading Windows security logs monitoring

Block emails from freshly registered domains

Email addresses in freshly registered short lived domains are increasingly used to send spam and malware. They are also used in spear phishing campaigns often combined with bitsquatting/typosquatting techniques to fool users into trusting the message content.

As long as spam block lists can be an efficient technique to limit amount of spam originating from well know spammers then they won’t provide protection against fresh or targeted campaigns.

The idea described below is build around dynamic block list building based on incoming email log and the sender’s domain age. It assumes parsing mail log or incoming mail queue in search for freshly registered domain names. In this PoC I’m using API to avoid issues with parsing different creation date formats coming directly from whois. The obvious bottleneck here is the amount of API queries that can be run in short time. To workaround this you should first create a baseline file or db table with senders’ domains that your server already saw and accepted in the past. If you have some central log repository then it shouldn’t be an issue. Obviously all the whitelists you might be using should be included as well. The whole flow should look like this:

Continue reading Block emails from freshly registered domains

Detecting ransomware with Windows event log

“Ransomware is a type of malware which restricts access to the computer system that it infects, and demands a ransom paid to the creator(s) of the malware in order for the restriction to be removed.” – wikipedia.

Over the last time ransomware is having a significant footprint on many organizations’ security. While the concept is rather simple the recovery is true pain in the neck and can take a lot of time. The worst are of course cases where malware sits on an important server over a long period of time making sure the backups get overwritten with an encrypted copies of files. File shares, databases are only the top of an iceberg.

Continue reading Detecting ransomware with Windows event log

Moving through the network. Detection.

Scenario – Getting credentials from memory

Having access to Windows box that is member of Active Directory you may attempt to dump credentials, kerberos tickets or NTLM hashes cached in memory. Local admin privileges are required for this and the goal is to obtain other users credentials with ultimate goal of gaining domain administrator privileges. Tools exist to accomplish that such as Windows Credentials Editor (WCE) or Mimikatz. These take advantage of how Windows Security Packages like kerberos.dll or wdigest.dll handle passwords provided to them during authentication allowing to read credentials from memory and present them in clear text. ‘Stolen’ hashes can be used directly to perform pass-the-hash on Windows and kerberos tickets can be used to gain access to other systems.

Running these tools on a system will not generate too many events. With standard Windows auditing enabled you should get event id 4688:

4688 - A new process has been created
New Process Name: D:\mimikatz.exe

Of course attackers won’t be dumb enough to run offensive tools without even changing their file names so creating alarms based on file name won’t be effective in most cases. Some AVs might recognize WCE and mimikatz as malicious and block them but these are fairly easy to evade so you shouldn’t rely on them to provide full protection.

Continue reading Moving through the network. Detection.

Detect and block layer 7 DDoS

A colleague of mine asked me recently “OK so we’ve got this busy environment with large legitimate load. How do we identify an anomaly and more importantly how can we block only the unwanted part of the traffic.”

That’s the never ending fight with vandalism. In many cases it all gets down to the resources available. But also in many cases a lot can be sustained thanks to good preparation and swift response.

OK so what distinguishes DDoS HTTP requests from legitimate ones? The answer is simple. DDoS must be automated to work and this means that some algorithm must be used to generate requests. HTTP floods to have desired impact use valid requests deploying additional techniques that aim to evade caching so every request needs to be processed by the web server and its’ backend. What’s worse well prepared attack will be preceded by a manual recon aiming to identify requests that have potential to generate larger load on the server’s backend.

Continue reading Detect and block layer 7 DDoS