When looking at monitoring enterprise security, many companies will consider a centralized Security Information and Event Management System (SIEM). Popular names in SIEM, such as ArcSight, Splunk, IBM QRadar, Elasticsearch and others, mention capabilities like event collection from virtually any source.  Such systems attempt to find security-related events using rules to examine logs.  At the root of this is the idea that logs such as the Windows Event Log contain security-related information.  In this in-depth article I compare the events, the rules and the value of performing SIEM with such (traditional) technologies, to IntelliGO Managed Detection and Response. Be warned, this will be both technical and detailed.

Windows Events

A primary source of information is the Windows Event Log, which is a debugging tool used by Windows administrators to log errors in applications or the operating system. Such logs fall into five distinct categories. While each has a role in debugging windows systems, and is ingested by a traditional SIEM, not all of them contain relevant security information.

Event type



An event that indicates a significant problem such as loss of data or loss of functionality. For example, if a service fails to load during startup, an Error event is logged.


An event that is not necessarily significant but may indicate a possible future problem. For example, when disk space is low, a Warning event is logged. If an application can recover from an event without loss of functionality or data, it can generally classify the event as a Warning event.


An event that describes the successful operation of an application, driver, or service. For example, when a network driver loads successfully, it may be appropriate to log an Information event. Note that it is generally inappropriate for a desktop application to log an event each time it starts.

Success Audit

An event that records an audited security access attempt that is successful. For example, a user's successful attempt to log on to the system is logged as a Success Audit event.

Failure Audit

An event that records an audited security access attempt that fails. For example, if a user tries to access a network drive and fails, the attempt is logged as a Failure Audit event.

Cybersecurity frameworks provide guidelines on the use of such logs; PCI DSS, SANS, NIST and others recommend using them to track Authentication Failures and System Changes. However, in practice, there are shortcomings in leveraging such logs for these use-cases, including insufficient information within them to make accurate determinations, and the sheer volume of (irrelevant) logs. 

  • Authentication Failures: The authentication failures and successes can indicate who is accessing a system. However, in practice these logs are written to for any process which requests authorization. So, within minutes, the number of entries can run into the thousands, creating a log of events that do not indicate a login attempt at all.  Further, these events do not indicate important information about the login itself in every log: How is the login being attempted? Locally? Through RDP? As part of a process? During privilege Escalation for a program installation? Is it being keyed in or part of a script or another process?
  • System Changes: The changes to Active Directory or the system (workstation or server) itself is something that many tools attempt to understand from these logs. However, many of the changes such as mounting of a USB Key, file writes, reads, registry modifications, program exe execution, PowerShell (by default) are not tracked in the log or are incredibly taxing to produce.

Limited Applicability to Securing Your Network & Endpoints

Many aspects of the Windows Event Log are based upon application error and debugging for developers and as a result are not very helpful for tracing any of the following: 

  • The Workstation: These events are usually captured from a central domain system or server and are rarely (if ever) captured from the endpoint. That’s because the compute to process and store this information is cost-prohibitive for most companies, forcing them to trace only the “security” log for login attempts, marginalizing any use of the log for cached logins or other attempts at compromise.
  • Network Activity: No logs are present for DNS, TCP Communication, which can be indicative of many command and control connections or exfiltration of data. In short, this is typically what you want to know when you’re looking to block an attacker.  Logs rarely contain IP Addressing let alone record of network communication.
  • File Monitoring: Access to critical files, writes, reads or modifications of programs are not logged in the event viewer. Typically, when monitoring security for unauthorized or malicious activity many of the files accessed or manipulated are a key indicator in assessing the activity. Even with file access monitoring, understanding what process modified what file is not possible so a malware trace is unusable.
  • Process Monitoring: What processes are doing to file system, registry or changes to Windows are very key aspects of malware detection are not tracked anywhere within the windows log unless they chose to write there. This leaves security analysts blind to the changes or activity performed by executables that they need when capturing a security event.
  • Registry Activity: Modifying the registry can allow persistence and changes to key aspects of Windows Operating Systems that malware designers use to compromise the host and persist on the system. Linking registry modifications to processes is not easily done by capturing event logs.

As such, the IntelliGO platform logs the categories of activity which can actually be used to identify behavior of malware, by using an agent (or, sensor). Our Endpoint Detection and Response (EDR) agent does not depend on writing to log files, nor on interpreting debug logs to determine whether a given behavior is malicious.

This agent allows our threat hunters to quickly identify malicious behavior without malware or attackers having the capability to delete the log file (a common tactic used to “cover their tracks”).  Additionally, IntelliGO can capture multiple events types with EDR, to ensure our threat hunters are not wading through non-security-related activity, or otherwise incomplete/unusable information.  Our foundation rests on usable information that can be layered to capture any activity about the operating system, which we can use to define a malicious event. Specifically: 



File Operations


File operations provide a very good indication as to whether the process is malware because signatures can be checked for the file and the activity of the process defined as malicious. Examples include Ransomware deleting backup files, or a PowerShell script that downloads executables. 

Registry Operations


Tracing registry operations allows rules to dictate when a process modifies a registry key that is suspicious such as core Windows registry entries for boot, login, tasks, services, startup and policies. Modifying the registry can allow malware to persist even when the files are deleted and system rebooted.

Network Communication


Understanding where a process is attempting to communicate across the network or outbound to malicious hosts helps qualify what firewalls track right down to the process.  It also allows lookups in threat intelligence to find malware just based on who is making the connection.

Process Activity


The most significant event category is one that is the least tracked in Windows by malware.  The event log was designed for developers to write their logs to a file for debugging.  Malware does not do this.  So, in order to track process behavior including sub-processes, parent processes and simple things such as what is the PowerShell commands that are running we need to trace these events. 

Useful Rules and Alert/Actions

A tenet of traditional SIEM is the creation, validation, management and revision of rules (to determine what the appliance notifies the person managing it of). This comes with a drawback, of “False Positives” – information which does not indicate a threat but creates an alert (based on the rule) anyway. The reason for that is because the events that are sent in the first place are placed into threshold rules to determine attack behavior. Ultimately this means that certain types of attacks are handled poorly, because of the way false positives overshadow the alert, or because of the absence of the necessary information to investigate. Let's look at how a traditional SIEM and IntelliGO MDR would deal with common attacks:


Typical SIEM Rules

IntelliGO MDR

Brute Force Login: Using a list of passwords or accounts programmatically attempt to login to an asset

5 Failed Login Attempts Same IP

5 Failed Login Attempts Multiple Sources

3 Failed Login Attempts followed by Success

Uses: Windows Security Log. 
Why it fails: false positives will bury any real brute force. Deleted accounts, normal behavior will always ensure you cannot rely on this in practice.

First Login Attempt after profile creation.

Uses: Windows Registry and process information not in logs.

Why it works: If attempting to login to Windows on a domain the accounts and passwords used will create a profile if successful. This allows threat hunters to detect malicious attempts.  
What about brute force attempts that are not successful? Our sensor audits for account lockout and attempts on Windows this should lockout the user and allow an investigation for threat hunters without needing to go through false positives.

Malware Infection: Download a virus and run it on the system

Logs from Anti-Virus Central Console provide “Virus Detected Log”

Suspicious Flows for DNS, DHCP or others.

Why this doesn’t work: If the AV agent is off, no coverage for the virus, logs haven’t been sent to the central console (user is at home) or high false positives from DHCP, DNS or other volume-based problems.

Known Malware Detected

Uses: File Creation or Network Communication to forward hash of files and kill in memory.

Why this works: The sensor runs kernel mode, all Major AV vendors signatures are synchronized so if there’s no coverage from your vendor another will have it.

PowerShell Attack: Run a malicious encoded script to download and run malware on the system

PowerShell command run encoded

PowerShell command executed

Uses: Custom PowerShell Logs

Why this doesn’t work: 
The log will capture the commands run by PowerShell but not help track the file activity once it’s downloaded

PowerShell Malicious Command Run

Uses: Process information and arguments and network monitoring

Why this Works: PowerShell itself causes actions the scripts that are run have changes to the OS if the only thing taken into account is the command and not the actions from the command encoding, encrypting or changing where instructions are read from will bypass detection (and do).

Event Categories and Prioritization

SIEM will sometimes refer to a taxonomy of events (categories), or rules associated with behaviors (as discussed above).  Traditional SIEM categories include things like Authentication, Policy, Reconnaissance, which associate event logs from various applications, including Windows.  On the other hand, IntelliGO MDR categorizes behavior and assigns an impact to help threat hunters investigate more quickly and be more flexible in terms of what they look for.  Here are specific examples of such behaviors, and how our platform scores/prioritizes them to enable our threat hunters to be more effective.

Use Case

IntelliGO MDR Event and Impact

PowerShell creates new Admin account

PowerShell: Admin Account Created “Name of Account”
Impact 100

USB Drive Plugged in for the First Time, followed by a program run from the USB Key that is malware.

USB Plugged in for the First Time “Name of Device”
Impact 10
Chain Event:  Process created from removable drive “process name”
Impact 10
Chain Event: Process matches malware hash
Impact 100

More Outcomes & Impacts; Less Events that May Lead to Them

By scoring cumulative impacts to the system, correlating events with complex rules is not required with IntelliGO MDR. The assets will gain a higher and higher score, for Threat Hunters to focus on more troublesome events.  This saves time and effort over correlation, especially for busy systems like directory or file server, which produce a lot of similar events that may not represent malicious activity.

Sample Categories include: Malicious File Activity, Malicious Script Behavior (PowerShell / WMIC / NETSH / BASH / CMD), Critical File Modified (System / Task Scheduler / Programs / Registry)

Storage Requirements:

Typically, event logs contain a large amount of extra information like codes or debug parameters, and they take up a lot of space as a result.  With the EDR data we are mindful of the storage requirements of our clients and that some may wish to store more information and others may not necessarily need a copy of every transaction.  As a result, our central systems keep roughly 60 days of data for EDR and Syslog and customer systems store metadata for as long as they require with the disk space of the client’s Virtual Machine dictating how much is kept.  This differs from a typical SIEM technology which will provide storage on appliances purchased by the customers at a much higher cost than traditional disk space.


As you can see, traditional SIEM appliances suffer from drawbacks like bloated collection of irrelevant logs; inconsistent rules that yield false positives which distract your security analysts; and, they lack the ability to assess the implications/outcomes of security events – leaving you unable to determine or prioritize the risk to your business. Conversely, through our modernized approach to SIEM functionality, IntelliGO MDR enables highly efficient processing of relevant logs, prioritized Threat Hunts based on the outcomes and implications of user/network/system behaviour, and flexible storage requirements to suit your needs. If you are ready to take a modern approach to SIEM functionality, so you can access the benefits I’ve described, reach out to us today and one of our experts can help you reclaim the value of your SIEM undertaking. Or, request a demo of our service, to see such functionality in action.

See Our MDR Service in Action

Request a Demo

Subscribe To Our Blog

New Call-to-action

Let us know what you thought about this post.

Please comment below.