Below is the list of blog posts with the “Windows” tag.

Most Windows detection programs are anchored on a small set of well-known event IDs: 4624, 4625, maybe 4688 if process creation auditing is turned on. The events that actually describe an intrusion (the new service, the scheduled task, the explicit credential, the share enumeration) live elsewhere on the same host, often on channels that are not enabled by default. We have written before about why a 4625-only mindset leaves most of the attack chain in the dark; this post is the catalog that picks up where that argument ended.

The default advice for any system running an unsupported operating system is simple: replace it. Upgrade to a supported platform. Move to modern hardware. Problem solved. It’s good advice in theory. As with many other things in life however, in practice it ignores everything that makes legacy infrastructure hard to deal with in the first place. For organizations running Windows XP, Server 2003, or other legacy 32-bit Windows systems, "just upgrade" is often the most expensive, disruptive, and operationally risky option on the table.

Compliance frameworks don’t have a checkbox for "we know it’s a problem, but we can’t afford to fix it right now." Yet that’s the position thousands of organizations find themselves in — bound by regulation to meet security standards that their operating systems are physically incapable of supporting. If you run Windows XP, Server 2003, or any other unsupported OS in a regulated environment, the compliance obligation doesn’t go away just because the upgrade path is blocked.

Somewhere in a hospital basement, an MRI machine hums along on Windows XP. Down the road, a CNC controller on a factory floor runs Windows Server 2003. Across town, a municipal utility manages water treatment with software that hasn’t seen an update since the second Bush administration. These aren’t edge cases. They’re everywhere — and they represent one of the most underestimated risks in enterprise security today. Still here, still running It would be reasonable to assume that operating systems from the early 2000s have no place in a modern network.

We are committed to the security of our customers, and wish to inform you of CVE-2025-67900, a recently published vulnerability affecting the Windows version of NXLog Agent 6.10 and older. Technical description The Windows version of NXLog Agent 6.10.10368 and older includes a Privilege Escalation vulnerability because it attempts to load an OpenSSL configuration file from the hardcoded and unintended directory C:\nxlog4\x64\ on startup. This is a legacy installation directory that may not exist in clean NXLog Agent installations.

In the past, we’ve written about monitoring file access in Windows. However, monitoring file access events alone doesn’t capture the full lifecycle of changes that matter for security and compliance. To gain true end-to-end visibility, you need to track not only when a file is accessed, but also when it’s modified, renamed, or deleted. In this guide, we’ll show how combining File Integrity Monitoring (FIM) with Windows Security Auditing delivers a complete file monitoring solution and how NXLog Agent ties these log sources together.

In our previous blog post, From network logs to insights: Visualizing OpenVPN logs with Elasticsearch and Kibana, we explored how you can gain visibility into VPN activity by collecting and analyzing network logs. Windows security monitoring is another common use case we encounter at NXLog. Windows workstations and servers generate security event logs ranging from authentication attempts and privilege escalations to policy changes and process executions. Such events can reveal external intrusions and insider threats, and for security analysts, they are the first line of evidence in investigating suspicious activity.

Nation-state-sponsored hacking stories are everyone’s favorite Hollywood movies — until our personal or corporate sensitive data shows up on the dark web for sale, being compromised. In real life, cyber espionage groups’s activities trigger security enforcement. First in the government sector, then the government standards slowly shift industry norms starting by gently forcing vendors who are also selling into government contracts. In the case of the recently announced playbook on MICROSOFT EXPANDED CLOUD LOGS IMPLEMENTATION PLAYBOOK, issued by the US Cybersecurity and Infrastructure Security Agency (CISA), it all started in July 2023, when the Chinese cyber espionage group Storm-0558 exploited a vulnerability in Microsoft’s Outlook email system to gain unauthorized access to email accounts belonging to U.

Monitoring and centralizing Remote Desktop logs is critical for IT security, compliance, and operational efficiency, and NXLog Platform makes it simple and scalable. Remote Desktop Protocol (RDP) is a powerful Windows feature that allows users to access a computer remotely over the network. While convenient and widely used, it’s also a potential entry point for attackers. Understanding how to check and analyze RDP connection logs can help detect unauthorized access, troubleshoot issues, and maintain system integrity.

One of the challenges that security-conscious Windows administrators face is collecting and centralizing Windows event logs. One of the obvious solutions that come to mind is the native Windows Event Forwarding (WEF) feature available on all modern Windows operating systems. WEF offers the convenience of forwarding Windows events to a central event collector without installing and managing agents. To objectively portray the role this valuable technology plays in the larger scope of enterprise log collection, we have written several articles that discuss it:

For those of us who manage network authentication and authorization, RADIUS is a familiar term. This protocol was introduced in the last century, and many of us from those days still remember the old-school diagrams, which surprisingly remain on the Cisco Systems website today. Figure 1. Interaction between dial-in user requests, the RADIUS client and server © Cisco RADIUS, which stands for Remote Authentication Dial-In User Service, was developed to address a specific challenge.

If you are capturing Windows Event Logs on a large scale, you know that the more logs you collect, the more resources you need. Thus, the more expensive your SIEM becomes. The main issue is a large amount of the log data you are sending to your SIEM contains no valuable information. This means you waste a sizable portion of your cost on what the industry calls “log noise”.

File access auditing is the process of tracking who reads, modifies, or deletes files on a system, providing a record of user activity for security and compliance purposes. On Windows systems, this is especially important for monitoring sensitive or business-critical files, such as financial records, HR data, or confidential customer information, where unauthorized access could result in a data breach or regulatory violation. In this post, I’ll show you how to enable file access auditing on Windows and use NXLog Agent to collect and forward file access events to help you protect sensitive data and meet compliance requirements.

PowerShell scripts can be used with NXLog for generating, processing, and forwarding logs, as well as for generating configuration content. In this article, we will take a look at how to execute PowerShell directly from NXLog. You can run a PowerShell script in multiple NXLog instances without using any PowerShell script file, and is achievable through having the script code directly in NXLog’s exec modules. This is ideal because if you need to make any change to the script, it’s easier to modify just the NXLog module rather than change the script on every computer used.

Windows DNS Server log collection is essential yet complex, primarily because Windows DNS Server provides logs in various places in different forms containing a vast amount of information. Nevertheless, we all know that DNS Server log collection is paramount in IT security. Getting it right can be challenging. The Windows DNS Server section in the NXLog Integrations Guides offers a comprehensive guide on collecting log records from a Windows DNS Server.

The Windows DNS debug log contains valuable information on DNS queries and activity that is especially useful for monitoring and analyzing malicious traffic. This requires some configuration changes for the DNS service in order to enable debug logging. Here is a short description on how to enable debug logging for the DNS service on windows, this also applies to Windows Server 2008 and later. It is possible to specify the file and path name of the DNS debug log file as well as the maximum size of the file.

As a security administrator, you may be inclined to focus on the Windows Security log within Windows Event Log. You might even go as far as filtering for specific event IDs, such as EventID 4625 (failed logon request), while forgetting there is much more to security logging on Windows than this single log source. The consequence of this narrow field of view is that you are not benefitting from the valuable information that other Event IDs used for security audit policies can offer.

If you’re a cyber security enthusiast, you’ve probably heard a lot about Windows Management Instrumentation (WMI) lately. There’s a good reason why this topic has gained popularity, however, this technology has been integrated into Windows operating systems for over 20 years now. In this blog post, we will delve into how WMI works, the risks resulting from misuse, and how to audit it with NXLog. A standardization effort The first thing to clarify about WMI is that it’s not a Windows-only technology.

DHCP server log collection made simple DHCP (Dynamic Host Configuration Protocol) is a network management protocol that dynamically assigns IP addresses to each client machine on your network. However, its importance does not stop there. DHCP can even generate numerous critical events that indicate your network’s security has been compromised. You might then wonder how you can use these events to safeguard your organization from intrusion. Well, these event logs store valuable information that contain the ID and IP address associated with each client.

It goes without saying that across your business infrastructure, there should be a commitment to protect not only the hardware and software assets, but the plethora of data that is transmitted through and stored in it. However, to successfully safeguard such data, it is imperative to have an effective audit policy in place that includes the collection of security events as its essential component. Windows provides a wealth of security logs that are visible in the built-in Security channel of Event Viewer.

Unquestionably, Microsoft Windows is the number one desktop operating system in the world, as well as having a significant share of the server operating system market. Multi-million-dollar organizations rely heavily on Windows Server and Active Directory to provide a safe, secure networked environment for their business operations. Such an enterprise infrastructure alone can generate thousands of events per second that range anywhere from benign user authentication events to logs indicating a severe software failure, or even more serious events such as DoS attacks or intrusion attempts.

Windows Event Forwarding (WEF) is a service available on Microsoft Windows platforms which enables the forwarding of events from Windows Event Log to a central Windows Event Collector. Since the technology is built into the operating system, this means you can centralize log collection without having to install third party software on each Windows node. You can also use Group Policy for configuring clients to forward their events. This approach not only standardizes client management but also streamlines it.

Be sure to read Part 1 and Part 3 of our DNS Log Collection series, in case you missed them. DNS Log Collection on Windows If you need to reduce the cost of DNS security and increase efficiency through centralizing DNS log collection, where would you start? Answering this question requires knowledge and awareness of the challenges and opportunities available on the Windows platform. While Windows DNS server is a common technology serving many types of organizations, from local domains to large multi-site enterprises, the possibilities are not necessarily that well-known within the context of comprehensive, site-wide log collection.

Windows Event Forwarding (WEF) provides log centralization capabilities that are natively supported in Windows-based systems. It is straightforward to set up since it is already built into Windows, and only a few pre-requisites are required, such as having a dedicated event server with a group policy object (GPO). Despite its ease of use and native support, WEF has some limitations. This post covers the advantages of using Windows Event Forwarding for centralized log collection, followed by limitations of WEF and its subsequent solutions.