Spotting the Adversary with Windows Event Log Monitoring
- Pavan Raja
- Apr 9
- 27 min read
Summary:
The passage provides a comprehensive overview of Windows Remote Management (WinRM) and Event Forwarding within the context of Microsoft Windows systems, particularly those running Vista and later versions. Here’s a summary of key points discussed in the text:
### WinRM Configuration - **Protocols and Ports:** - HTTP: 5985 for WinRM 2.0 (non-SSL), 5986 for HTTPS (SSL). - WinRM 1.1 uses standard HTTP/HTTPS ports but with specific configurations. - **TrustedHosts Configuration:** - These hosts do not need to be authenticated for remote management, which can simplify the configuration and improve security by allowing only trusted systems to connect remotely. - **Client Configuration:** - Parameters such as RootSDDL, MaxConcurrentOperations, and others are customizable via registry settings. - SDDL (Security Descriptor Definition Language) is used to define access control for remote management listeners, ensuring that only authorized users or computers can access the service.
### Event Forwarding Plugin - **Error Handling:** - Errors during subscription creation might include "The subscription is saved successfully, but it can't be activated at this time" or "Failed to open subscription." These could be due to firewall exceptions being disabled, the Event Collector not running, insufficient permissions, incorrect username/password, or Windows Firewall service not running. - Access denied errors in WinRM commands require checking user permissions and ensuring that necessary configurations are set for secure connections. - **Troubleshooting Commands:** - Useful command line options include `winrm help`, `winrm id –remote:TARGET`, `winrm get wmi/root/cimv2/Win32_Service?Name=WinRM`, and others. - **Operational Logs:** - Location of operational logs includes Microsoft > Windows > EventCollector > Operational, Microsoft > Windows > Eventlog-ForwardPlugin > Operational, and Microsoft > Windows > Windows Remote Management > Operational. - Use `wevtutil` to query the Event Forwarding log with specific parameters for more information.
### Diagnosing Issues - **Event ID 101:** - This event is associated with errors in the Event Forwarding Plugin, typically indicating an invalid XPath query or other configuration issues. - To diagnose, locate the event with ID 101 in the specified operational logs and check the "Status" data node for a Win32 error code; if it’s 15001 (invalid query), refer to MS-ERREF for ERROR_EVT_INVALID_QUERY.
### Conclusion The passage serves as a guide to configuring, troubleshooting, and diagnosing issues with Windows Remote Management in Microsoft Windows systems. It emphasizes the importance of proper configuration through SDDL settings and authentication mechanisms, while also providing methods for error resolution using available tools and command line options.
Details:
The document "Spotting the Adversary with Windows Event Log Monitoring" provides a comprehensive guide for organizations to enhance their cybersecurity by monitoring Windows event logs, particularly on servers running Windows Server 2008 R2. Key aspects include deployment strategies, environment requirements, and specific recommendations for collecting various events such as application whitelisting, crashes, system failures, and more. It also emphasizes the importance of firewall modification, disabling unnecessary services like WinRM (Windows Remote Management), and SSL/TLS encryption in communications to improve security posture against cyber threats. The document is part of a series by NSA/CSS's Network Components and Applications Division and has been revised on December 16, 2013.
This document outlines a comprehensive set of recommendations and provides detailed guidance on various aspects related to Windows Remote Management (WinRM) version 2.0, including the creation and management of event subscriptions for data collection and analysis. The content is structured into several sections which include final recommendations, an appendix with specific technical details such as subscription configurations, troubleshooting guides, and a list of referenced figures and tables that provide visual aids and detailed information on events, registry keys, firewall settings, and more.
The main body of the document consists of:
**Final Recommendations** (page 34), which are concise suggestions for practical actions based on research findings or experiences. These recommendations include steps like configuring subscription properties to optimize data delivery and managing event sources through Group Policy Objects (GPOs).
**Appendix** (pages 35-48) which serves as a supplementary section providing detailed technical information including:
**Subscriptions** (7.1), explaining how to create and configure them for effective data collection.
**Event ID Definitions** (7.2), detailing the types of events that can be monitored through WinRM.
**Windows Remote Management Versions** (7.3), which provides an overview of different versions of WinRM and their configurations.
**WinRM 2.0 Configuration Settings** (7.4) offer specific instructions on how to set up the necessary registry keys and values for effective remote management through WinRM.
**Troubleshooting** (7.6), which provides a guide to resolve common issues faced during implementation or usage of WinRM.
**Works Cited** (page 48) is a list of sources cited in the document, including figures and tables that aid understanding and practical application of the information provided.
This structured approach aims to provide both theoretical guidance on event management and hands-on technical instructions for implementing changes within an IT environment using Windows systems.
This document appears to be a technical guide or report that lists various tables numbered from 4 to 24, each detailing specific events or activities related to system and network management in IT environments. The primary focus seems to be on cybersecurity and systems administration within an organization's infrastructure.
The breakdown of the content includes:
**Table 4**: System Events - This table likely contains information about various system errors, warnings, and other significant events that might affect the operation or performance of the IT systems.
**Table 5**: Windows Update Failed Events - Details any failures in Windows updates which could indicate issues with software installations or patches.
**Table 6**: Firewall Events - Logs related to firewall activities, providing insights into network security configurations and potential breaches.
**Table 7**: Log Activity Events - Records of user activity within the system logs, possibly indicating who accessed what resources and when.
**Table 8**: Software and Service Events - This table could document events or errors related to software installations, uninstallations, or other service disruptions.
**Table 9**: Account Activity Events - Logs detailing activities associated with user accounts, such as login attempts, account creations/deletions, or password resets.
**Table 10**: Kernel Driver Signing Events - Information about the signing of kernel drivers which is crucial for ensuring system security and stability.
**Table 11**: Group Policy Errors Events - This table would list errors related to group policies that manage aspects like user rights, local policies, etc., in an Active Directory environment.
**Table 12**: Windows Defender Activities Events - Logs of activities conducted by the Windows Defender antivirus software, useful for assessing its performance and detecting potential threats.
**Table 13**: Mobility related Events - Information about devices or systems that are mobile or have mobility features, such as docking stations or wireless connectivity issues.
**Table 14**: External Media Detection Events - Records of when external media (like USB drives) is connected to the system, which can be used for data transfer and security purposes.
**Table 15**: Printing Services Events - Logs regarding printing errors, configurations, or events that might indicate issues with printers or print services in a network environment.
**Table 16**: Subscription XML Description - Information about subscriptions or licensing details documented in an XML format, which is useful for managing software usage rights and compliance.
**Table 17 to Table 18**: WinRM Version Correlation and Update URLs - Tables detailing the versioning of Windows Remote Management (WinRM) and the corresponding update URLs needed for upgrades or troubleshooting.
**Table 19 to Table 24**: Various configurations, settings, and error logs related to networking protocols, client configurations, services, registry values, XML XPath errors based on OS versions, etc. These tables are technical in nature and provide detailed information about how the IT systems are configured and might require attention or correction due to system events.
**Disclaimer**: The disclaimer at the end of the document is a standard legal notice that disclaims any warranties and absolves parties from liability for damages arising from use of the guide, especially emphasizing the protection of government agencies and their representatives from claims based on usage of the item. The overall purpose seems to be providing detailed information about various system events and activities within an organization's IT environment, aimed at helping in the diagnosis and resolution of issues or compliance monitoring with regulatory standards related to IT operations. This document discusses the importance of collecting event logs from Windows workstations in enterprise networks to monitor network health and detect malicious activities. It introduces the use of built-in tools in Microsoft Windows OS for central event log collection on a Windows Server 2003 R2 or above version, which is free of additional licensing costs but depends on additional storage hardware. The paper provides guidance for United States Government and Department of Defense administrators to configure this feature using Group Policy. It highlights the recommended set of events to collect across client and server versions of Windows, emphasizing that product-specific events should also be centrally collected. The document is structured into three main parts: Deployment focuses on configuring and deploying central log collection; Hardening Event Collection deals with security hardening; and Recommended Events to Collect describes which events are recommended for collection. It mentions testing was conducted using Windows 7, Windows Remote Management (WinRM) 2.0, a Windows 8 client with WinRM 3.0, and a Windows Server 2008 R2 as the central event collection server. The Windows Collector service is used to collect specific events from domain and non-domain computers for viewing on a single computer via Event Forwarding feature, which can operate in pull or push modes depending on network configuration. To create an auditor's group with reduced permissions for Application, System, and Security log files, follow these steps: 1. **Create Auditor’s Group**: Set up a new group specifically designated as the auditor's group within the domain. 2. **Set Permissions**: Modify the Full control privileges of the Administrators group to Read and Execute only for Application, System, and Security log files. 3. **Implement Defense in Depth**: Recognize that this single measure can be bypassed; therefore, adopt a multi-layered security strategy. 4. **Use WinRM without Auditor’s Group**: Note that using Windows Remote Management (WinRM) does not inherently require an auditor's group. 5. **Event Log Reader Group**: In Windows Vista and later versions, there is an Event Log Readers group which serves to regulate remote access to local event logs. 6. **Domain Policies for Local Event Logs**: Enable domain policies such as "Manage auditing and security log" (found under Computer Configuration > Policies > Windows Settings > Local Policies > User Rights Assignment) to control user and group access to audit logs. 7. **Generate Security Audits Policy**: Configure the policy named Generate security audits to create a whitelist of users or groups that can write to the audit log, restricting this capability to Local Service and Network Service only (found under Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment). 8. **Enhanced Mitigation Experience Toolkit (EMET)**: Use EMET for enhanced security features on operating systems and applications hosted by svchost.exe, ensuring all security settings are enabled for this service. 9. **Audit File System Policy**: Enable Audit File System policy with Success selected to log file system events, which aids in identifying who accessed the event log files. 10. **Event Collector Role**: Utilize a dedicated server for logging user or group access to .evtx files and prevent additional roles from being assigned to this server. 11. **WinRM Version Requirements**: Ensure your environment uses WinRM 2.0, which is installed by default with Windows 7 and Windows Server 2008 R2. For other versions like Windows XP SP3 and Windows Vista, update to use WinRM 2.0 as per KB968930 <6>
requirements.
12. **Windows Management Framework**: Understand that WinRM is part of the Windows Management Framework core package, with updates such as KB968930 installing PowerShell 2.0 along with WinRM 2.0, requiring .NET Framework 2.0 SP1 or later for installation.
By following these steps and guidelines, you can effectively set up an environment where the auditor's group has restricted access to necessary log files while maintaining robust security practices across your network infrastructure.
This document provides guidance for configuring a Windows Server 2008 R2 event collector to aggregate logs from various sources within the same domain or different domains, using Source-Initiated subscriptions. It emphasizes the importance of isolating the event collector and recommends local configuration rather than relying on Group Policy Object (GPO) settings, which can lead to misconfiguration of the Windows Event Collector service.
The document outlines steps for configuring the Windows Remote Management (WinRM) and Windows Event Collector services on the event collector server:
1. **Service Configuration**: Both WinRM and Windows Event Collector services are set to start automatically with a delay, ensuring they do not conflict with other auto-start services. This is achieved using the quickconfig option in the command console for both services, requiring administrative privileges.
2. **Configuring Services via Quick Config**: The document provides specific commands for configuring WinRM and Windows Event Collector services:
For WinRM, use `winrm qc` with appropriate options to configure it as a Delay-Start service.
For the Windows Event Collector service, use `wecutil qc` similarly to set its startup type to Delay-Start.
3. **Creating Event Subscriptions**: Custom event subscriptions can be created via GUI or command line for organizing and filtering events based on user requirements. However, caution is advised against deploying these configurations on production servers due to potential capture of unnecessary data.
In summary, the document emphasizes local configuration over GPO settings and provides detailed steps for configuring essential services like WinRM and Windows Event Collector on a dedicated server within the network.
To create a subscription in the Event Viewer for collecting events, follow these steps:
1. **Open Event Viewer**: Start by opening Event Viewer (eventvwr.exe). It is recommended to do this with administrator privileges.
2. **Create Subscription**: From the Actions panel, select "Create Subscription..." and provide a name for your subscription.
3. **Select Source Computer Initiated Option**: Ensure this option is selected under 'Subscription Properties'.
4. **Define Computer Groups**:
Click on the "Computer Groups…" button.
Add domain computers by clicking "Add Domain Computers..." and enter the group name, e.g., EventSource.
Check the entered group name for accuracy before confirming with "OK".
5. **Configure Subscription Properties**: Review and confirm all settings in the 'Subscription Properties' window to ensure they are correct. Click 'OK'.
6. **Set Up Filtering Events**:
In the Query Filter window, select Event Level options and choose all levels.
Select "By Log" from the drop-down list and choose specific logs such as Application or System. Click 'OK'.
7. **Review Default Settings**: The default settings will collect events, keywords, task category, and from all users and computers. No further customization is needed unless specified.
8. **Configure Advanced Subscription Settings**:
Click the "Advanced…" button.
Set the frequency of event delivery to Normal, keeping the protocol as HTTP. Confirm with 'OK'.
9. **Event Delivery Optimization**: Adjust collection intervals between 15 minutes (Normal), 6 hours (Minimize Bandwidth), or 30 seconds (Minimize Latency) using wecutil command line utility.
10. **Complete Subscription Setup**: Review all settings and confirm the completion of subscription setup. The completed subscription will be stored at a predefined log location under 'Forwarded Events'.
**Custom Subscriptions**: For more specific needs, customize frequencies and batch amounts as required by editing subscription schema details found in appendix sections.
**Troubleshooting**: If encountering errors such as "the type initializer for ‘AdvanceSettings’ threw an exception", ensure the current account has sufficient permissions.
This process outlines the steps to set up a basic or customized event collection subscription using Event Viewer, tailored based on enterprise requirements and specific events of interest.
The Event Viewer in Windows Vista allows users to create custom views that organize event data based on a custom filter, which can act as a subscription for identifying collected events. To create a custom view:
1. Open the Event Viewer and select "Custom Views" from the left panel.
2. Right-click and choose "Create Custom View…".
3. Choose a time range (e.g., Last 7 days) or, if needed, use a "Custom range …" option.
4. Select an appropriate event level.
5. Set "By log" to "Forwarded Events".
6. Enter the Event ID(s) in the text area.
7. Provide a custom view name and click OK.
The newly created custom view can be organized by creating a new sub-directory within %ProgramData%\Microsoft\Event Viewer\Views, naming it meaningfully (e.g., "Last 24 hours"). This requires a privileged account. To display the directory, refresh the Event Viewer's left panel.
Custom views are essentially saved XPath queries that filter events based on criteria like time and level. XML files in these directories represent custom views, automatically creating an XPath query for event selection. Users can also manually enter XPath queries through the Create Custom View dialog under the "XML" tab.
Alternative filtering options include PowerShell's Get-WinEvent and Get-EventLog Cmdlets, which offer more granular filtering via other PowerShell Cmdlets.
Additionally, configuring source computer policies for event forwarding involves setting up Group Policy Objects (GPO) on Windows 7 and above systems to enable reading default log files like the Security log for delivery to a collector. This includes creating new groups and GPOs named EventSource, applying settings, and ensuring members are notified of their membership through reboots if necessary.
Lastly, managing remote event forwarding is done via Group Policy (GP) for Windows 7 and above systems using WinRM, which can be enabled via System Service policy with predefined firewall rules handled by Active Directory to simplify the process without manual execution on all source computers.
To configure Windows Remote Management (WinRM) and enable Event Forwarding in Group Policy, follow these steps:
### For WinRM Configuration:
1. **Navigate to Group Policy Management Editor**: Go to `Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Remote Management > WinRM Service`.
2. **Set the Allow automatic configuration of listeners policy** to **Enabled**.
3. **Configure IPv4 and IPv6 filter values** to `*` in the "WinRM listener's IP Filter Options" dialog. This allows WinRM to listen on any IP address for both protocols (IPv4: 0.0.0.0, IPv6: ::).
### For Event Forwarding Configuration:
1. **Navigate to Group Policy Management Editor**: Go to `Computer Configuration > Policies > Administrative Templates > Windows Components > Event Forwarding`.
2. **Enable Event Forwarding** by setting the "Configure the server address, refresh interval, and issuer certificate authority of a target Subscription Manager" policy to **Enabled**.
3. **Click the Show… button** in the dialog for configuring the Subscription Manager settings.
4. **Set the Server option**: Enter the FQDN or hostname followed by `http://FQDN:5985/wsman/SubscriptionManager/WEC` (or use HTTP without specifying a port if WinRM versions are mixed). If using HTTPS, specify `https`.
5. **Optionally set Refresh and IssuerCA**: These can be omitted unless needed for specific configurations; they include the number of seconds to send events to the server and the thumbprint of the client's certificate authority.
6. **Once configured**, click OK in the Subscription Manager dialog to save settings.
These steps will configure WinRM listeners and enable event forwarding, allowing communication between sources and a subscription manager via WinRM.
Enabling the compatibility HTTP listener in WinRM (Windows Remote Management) allows older versions of WinRM to communicate with newer ones by binding it to port 80 and redirecting traffic to port 5985. However, this can introduce security concerns due to an additional open port. To avoid this, specify port 5895 when configuring the subscription manager for sources.
On Windows 7 (and above), sources are not allowed to read event logs for event forwarding; they need to add the NETWORK SERVICE account to the Event Log Readers group in Restricted Groups under EventSource GPO. This is done by adding the account to the Event Log Readers group and setting it as a member.
To disable Windows Remote Shell (WinRS), set the policy Allow Remote Shell Access to Disabled via Group Policy or using the command line winrm set winrm/config/winrs @{AllowRemoteShellAccess=”false”}. WinRS should be disabled for all servers and clients in the domain to mitigate security risks.
Enabling event collection with WinRM introduces an additional attack vector, so it's crucial to isolate sources and collectors to limit potential attacks. For environments with firewall rule merging restrictions, removing these can help configure locally applied WinRM firewall rules, although this is not a standard practice for most environments.
To enable Windows Remote Management (WinRM) firewall exceptions in Windows Server 2008 R2 using Windows Firewall with Advanced Security, follow these steps:
1. **Enable Windows Firewall with Advanced Security**: Ensure that the policy is enabled for all network profiles (Domain, Private, and Public). This can be done through Group Policy or by directly modifying settings on the local machine.
2. **Manage via Graphical User Interface (GUI) or Command Line**:
**Graphical User Interface**: Navigate to `Computer Configuration > Policies > Windows Settings > Security Settings > Windows Firewall with Advanced Security > Inbound Rules`. Create a new rule by right-clicking on "Inbound Rules" and selecting "New Rule...". Choose "Windows Remote Management" from the predefined list, select "Allow the connection", and finish the setup.
**Command Line**: Use commands like `netsh advfirewall firewall set rule name="Windows Remote Management (HTTP-In)" new enable=yes` to automatically configure the firewall rules without navigating through GUI options.
3. **Apply Firewall Rule to All Profiles**: The WinRM firewall rule should be applied to all network profiles to ensure proper functioning across different network environments. Any modification that selects only a specific profile might result in errors or failures when subscriptions are running and sources communicate with the subscription manager.
4. **Verify Configuration**: After enabling the rules, verify that the firewalls are enabled through the Windows Firewall interface (netsh advfirewall show allprofiles) and check if any ports are open as required by WinRM configurations.
5. **Update Group Policy (GPO)** to reflect changes made in firewall settings. Use `gpupdate` command or manually refresh group policy settings on client machines.
6. **Troubleshooting**: If no events are received, it indicates a need for troubleshooting techniques such as checking event logs and verifying the status of WinRM services using netsh commands.
7. **Security Considerations**: Be aware that enabling WinRM without proper security configurations can expose systems to attacks where an attacker could move laterally within a network through accessing WinRM services. Ensure strict access controls and consider potential mitigations against such threats based on your specific environment's needs.
This text discusses the process of customizing firewall rules to only allow connections between a specific collector and source machine, using Group Policy in Windows settings under Computer Configuration > Policies > Windows Settings > Security Settings > Windows Firewall with Advanced Security > Inbound Rules. It outlines how to add selective IP addresses for both the source and collector machines within these predefined WinRM firewall rules.
It also provides detailed steps to modify these configurations on both sources (referred to as "Source Firewall Modifications") and collectors ("Collector Firewall Modification"), specifying an IP scope that allows only connections between the designated devices. The article mentions configuring a whitelist for better security, ensuring that only authorized traffic is allowed through WinRM firewall rules.
In case of errors while viewing subscriptions in Event Viewer, it suggests verifying if the firewall profile for the rule is enabled and applying necessary exceptions or correcting any incorrect modifications made to the firewall settings.
The text also covers disabling WinRM (Windows Remote Management) and Windows Collector Service on both sources and collectors, which can be achieved by stopping these services through the Services MMC snap-in in Microsoft Management Console. Finally, it provides information on how to securely configure WinRM authentication methods such as Basic Authentication, Digest Authentication, Credential Security Support Provider, Negotiate Authentication, Kerberos Authentication, Client Certificate-based Authentication, and Channel Binding Token.
The article outlines several recommendations for configuring authentication methods in WinRM (Windows Remote Management) to enhance security. Here are the key points:
1. **Basic Authentication**: It is recommended to disable basic authentication as it does not support encryption and can be intercepted easily. Both client and service configurations should be set to disabled.
2. **Digest Authentication**: This method involves a challenge-response scheme which, although more secure than Basic Auth, is not supported by the WinRM service. Therefore, setting the client configuration to false and disallowing digest authentication on the service are recommended.
3. **Credential Security Support Provider (CredSSP)**: CredSSP provides SSO capabilities but is only available for WinRM 2.0. Both client and server configurations should be set to disabled.
4. **Negotiate Authentication**: This method offers a choice between Kerberos and NTLM authentication, with Kerberos being the default if it's not supported by the system. It is recommended to maintain this setting unless there are specific reasons to disable it, which may lead to issues.
5. **Kerberos Authentication**: Kerberos version 5 should be used for communication between client and server. The policy should remain enabled as per default settings but can be adjusted based on network configurations.
6. **Client Certificate-Based Authentication**: Enabling this feature allows the service to verify the authenticity of the connecting client through its certificate. Both client and service configurations should be set to false, although there is no direct Group Policy setting for this in Windows.
7. **Channel Binding Token (CBT)**: This method uses TLS to secure communication channels between a client and server, providing protection against Man-in-the-Middle (MitM) attacks. It is not directly configurable via Group Policy but can be managed through command line settings or other security measures.
In summary, the article emphasizes the importance of configuring WinRM authentication methods with security in mind, especially since many of these configurations are enabled by default and may pose vulnerabilities if left unaddressed.
This text discusses security measures and practices related to Windows Remote Management (WinRM), which is used for managing systems remotely over the network. It highlights several aspects including authentication methods, secure communication protocols, trusted hosts, and recommended event collection for monitoring system activities.
Authentication methods include Negotiate (which can be enhanced with Channel Binding Tokens for improved security) and Trusted Hosts where non-domain members are allowed without authentication. For secure communications between the server and client, TLS/SSL is recommended, especially when using WinRM for non-domain computers. Event Forwarding allows monitoring of system events across a network, requiring encryption (using integrated Windows Authentication or HTTPS) to protect data integrity and privacy.
The text also recommends specific event types for collection in an IT security context, emphasizing the importance of reviewing these events within their appropriate contexts as not all collected events are necessarily malicious. It advises configuring Domain Controllers or Member servers for Event Forwarding when collecting certain recommended events like account logons, which only occur on Domain Controllers.
In summary, this text provides guidelines and best practices for securing WinRM communications and monitoring system activities, emphasizing the importance of appropriate authentication methods and secure communication protocols to prevent unauthorized access and protect data integrity in remote management scenarios.
The text discusses the importance of monitoring various events on a local machine, especially in non-domain settings where security is more challenging. It outlines specific types of events that should be monitored for potential security threats or issues.
Firstly, it mentions Application Whitelisting which involves keeping track of applications that have been blocked from execution due to malware, unapproved software, etc. This can be done using Software Restriction Policies (SRP) on Windows XP and above, or AppLocker available only for Enterprise and Ultimate editions of Windows 7 and above. Events related to this are logged with specific ID numbers in the Event Log under the respective services like Microsoft-Windows-AppLocker/EXE and DLL, MSI and Script etc.
Secondly, it addresses Application Crashes which could be due to malware or benign issues. These include Blue Screen of Death (BSOD), Windows Error Reporting (WER), Application Crash, and Application Hang events. If the organization uses EMET, then logs from this toolkit can also be collected. The relevant events are logged under sources such as Application Error, EMET, SystemErrorReporting etc.
Thirdly, it covers System or Service Failures which need to be monitored for potential service disruptions that could indicate an attack targeting specific services. These are usually indicated by failure in Windows services and are captured under the Microsoft-Windows-ServiceControlManager logs.
Fourthly, it touches upon issues with Windows Updates where machines should stay updated to avoid vulnerabilities. If updates fail, this needs investigation as it might lead to application issues or OS/application vulnerabilities. Logged events include those from WindowsUpdateClient and Setup servicing sources.
Lastly, it discusses the monitoring of firewall settings on client workstations for changes in status which should not be modified by normal users. These are logged under Microsoft-Windows-Windows Firewall with Advanced Security source when there's a change or failure to load rules.
The text also advises that event log data is unlikely to get cleared during normal operations, and if it does, it might indicate malicious intent. Therefore, events related to clearing logs like Event Log was Cleared (104) are significant for monitoring.
Additionally, the installation of software or services on a network should be monitored as part of routine network operations. This includes application whitelisting, crash monitoring, system service failures, Windows update errors, firewall status changes, and clearing event logs. Collecting these events centrally can help prevent malicious activities such as covering tracks through clearing log data.
The provided text discusses monitoring software installations and service updates on Windows systems, focusing specifically on events logged through Microsoft's Application Experience component. This system tracks activities such as kernel filter driver installation (Event ID 6), new Windows services (Event ID 7045), MSI file installations (Event IDs 1022, 1033), and application updates or removals (Event IDs 903-908). A daily summary event (ID 800) is generated to provide a weekly log of software activities.
The text also covers the role of Program Data Updater in collecting telemetry information, which can be opted into for participation in Microsoft's Customer Experience Improvement Program. This tool helps track application activities without requiring CEIP opt-in but does not apply to standalone executables.
Additionally, the document discusses user account auditing through various event logs that capture details such as successful and failed logins (Event IDs 4624, 4625), explicit credential login attempts (Event ID 4648), and lockouts (Event ID 4740). These events are crucial for detecting unauthorized access and potential malicious activities.
The text does not provide a detailed analysis or conclusion but outlines several key aspects of monitoring software installations, account usage, and auditing in Windows environments using these event logs.
The provided text appears to be a summary of various security and system event logs generated by different components in Windows operating systems. Here is a condensed version of the content presented:
4.9 **Kernel Driver Signing**
Introduced in Windows Vista 64-bit, kernel driver signing enhances defenses against malicious drivers or activities in the kernel.
Indications of altered protected drivers may suggest malicious activity or disk errors and require investigation.
Relevant events include:
Event ID 4624 provides detailed information about each event.
Table 10 lists various kernel driver signing events such as invalid image hash, page hash, and failed kernel driver loading.
4.10 **Group Policy Errors**
Group Policy management allows administrators to secure domain computers.
Inability to apply policies due to group policy errors reduces the benefits of enhanced security and regulation.
Key events include internal errors, generic internal errors, and failed application of group policy due to connectivity issues.
Table 11 outlines these error events in detail.
4.11 **Windows Defender Activities**
Windows Defender combats spyware and malware with its antispyware and antivirus features.
Administrators should investigate notifications related to detecting, removing, or failing to remove malicious programs.
If the third-party antivirus is active, collection of these events may not be necessary.
Table 12 covers various Windows Defender activities including failed scans, malware detection, real-time protection failures, and unexpected errors.
4.12 **Mobile Device Activities**
Tracking wireless device activities in enterprises is crucial for security purposes.
Events track mobile devices' network connections, wireless connection statuses, and WLAN operations.
The frequency of these events depends on the device's disconnection and reconnection patterns to networks.
Table 13 lists detailed information about these events as they relate to mobile devices.
Each section provides a brief overview followed by specific event IDs and their associated sources within Microsoft documentation sites for further reference.
This document discusses several operational and security-related events in Windows operating systems, particularly focusing on wireless network connectivity issues, USB device detection, printing services, and passive hash tracking. The document is relevant for users who need to understand and manage these aspects of their IT infrastructure.
Wireless Network Connectivity Issues are monitored through specific event IDs such as 11002 (Status), 11004-5 (Wireless Security), and 8002 (Wireless Connection). These errors can be tracked in the Microsoft-Windows-WLAN namespace, with detailed logs that include whether they are informational or error-level events.
For USB device detection, Windows 8 and above systems use Event ID 43 to detect new devices like mass storage devices. This is logged under the Microsoft-Windows-USB-USBHUB3-Analytic trace session log. The events can be tracked as "New Device" (ID 43) or for specific types of USB devices such as "New Mass Storage" with IDs 400 and 410, both under the Microsoft-Windows-Kernel-PnP namespace.
Printing services in Windows are logged through Event ID 307 within the Microsoft-Windows-PrintService/Operational log when a document is printed. This event is used for tracking printing activities but should be considered more as historical data rather than an audit trail due to potential excessive logging based on activity.
Lastly, detecting Pass the Hash (PtH) attacks involves configuring custom XML views in the Event Viewer with XPath queries. PtH related events are captured through LogonType 3 with NTLM authentication when a local account attempts to connect remotely from an unauthorized machine outside the domain, triggering event ID 4624 under the Security log.
Overall, these logs and events provide crucial information for monitoring system performance, security incidents, and user activities within a Windows environment. They are particularly useful for IT administrators who need to proactively manage network configurations, troubleshoot connectivity issues, track hardware changes (USB), and monitor potential security breaches like PtH attacks in networked environments.
This document discusses various aspects related to logging configurations, including log retention policies, remote desktop protocol (RDP) logon detection, and troubleshooting failed logons in a cybersecurity context. The information is primarily focused on configuring Event Viewer for Windows environments, particularly within an enterprise setting where multiple workstations and servers are involved.
**Event ID 4625:** This refers to the event triggered by a failed logon attempt when attempting to move laterally using Pass-The-Hash (PtH) technique. It is characterized by:
**Log Level**: Security
**EventID**: 4625
**LogonType**: Typically, this would be '3' for network logons.
**Authentication Package Name**: Most likely 'NTLM'.
**TargetUserName and TargetDomainName**: Should not include 'ANONYMOUS LOGON' or the specific domain name as defined in policies.
**Remote Desktop Protocol (RDP) Logon Detection:**
Custom queries are used to identify RDP logons, which can be distinguished by:
**Event IDs**: 4624 for login and 4634 for logout events.
**LogonType**: Indicated as '10' specifically for Remote Interactive logons.
**Authentication Package Name**: Typically 'Negotiate'.
**Event Log Retention:**
For optimal performance and usability, the Forwarded Events log file size should be set to approximately 1GB with an option to archive when full. This setup is crucial as larger logs can slow down system responsiveness and visualizations in Event Viewer. For client workstations and servers in a Department of Defense (DoD) environment, adhering to specific DISA STIG guidelines for other log file sizes is recommended but not mandatory for non-mentioned logs during event forwarding configuration.
**Final Recommendations:**
Centralized collection and retention of relevant events from various sources helps enterprises monitor network activities more effectively while reducing operational costs associated with unnecessary storage and bandwidth usage. Proper configuration of such logging mechanisms should be aligned with overall cybersecurity strategies to ensure appropriate protection against potential threats.
This document provides detailed information on configuring and managing event subscriptions for Windows 7 and Windows Server 2008 R2 computers to collect and forward logs. It includes PowerShell scripts, subscription XML files, and instructions for creating custom subscriptions using the `wecutil` command line tool. The purpose is to streamline audit processes by reducing administrative burden while enhancing detection of unauthorized or malicious activities through targeted event collection.
### Key Points:
1. **Event Subscription Basics**: Windows uses subscriptions to define which events from specific computers should be collected. These can be customized for individual requirements.
2. **Creating Subscriptions with `wecutil`**: The process involves creating a subscription XML file, activating it with `wecutil cs`, setting permissions using SID values, and verifying the configuration with `wecutil rs`.
3. **Subscription XML Structure**: Describes what events to collect (e.g., all levels of Application log) and specifies conditions for collection (from Domain Computers and Controllers).
4. **Configuration Details**: Explains each node in the subscription XML file, such as `QueryList` for event filtering and `Locale` for language settings in responses.
5. **Security Considerations**: Utilizes Security Descriptor Definition Language (`SDDL`) to manage permissions and access controls.
### Additional Information:
The provided sample subscription is intended for testing only due to its high data collection volume; it is not recommended for production use without modifications.
All files related to this guide can be accessed via the IAD GitHub site, with URLs pointing to resources like (https://github.com/iadgov).
### References:
The document includes DISA STIG references for Windows 7 and Windows Server 2008 R2 versions, indicating compliance standards.
Detailed command reference at the end of the document is linked to `wecutil ss -?` for further assistance in configuration and management.
This guide aims to facilitate efficient event log management through automated and targeted collection methods, ensuring minimal administrative overhead while maximizing detection capabilities.
This document outlines the setup and usage of Event Forwarding in security systems, focusing on recommended events to collect from various operating systems like Windows 7, Windows Vista, and Windows Server versions, particularly those starting from Windows Server 2003. The guidance includes sample subscriptions for automated event collection, detailed definitions of specific event IDs that are significant across different platforms, and information about the Windows Remote Management (WinRM) versions supporting these operating systems.
Key points:
1. **Event Collection Subscriptions**: Available scripts and subscriptions in EvtFwdSubscriptions_r.zip can be used to automate event collection from recommended events for Windows 7 and above workstations, which are outlined in the document's Recommended Events section.
2. **Event ID Definitions**: The document provides a list of significant event IDs that should be monitored based on specific operating systems or environments where third-party applications might be utilized for monitoring. It also offers resources to understand these events further through Microsoft’s Event and Errors Message Center, as well as detailed information about auditing policy from Windows Server 2003 Security Guide.
3. **WinRM Versions**: The document details the versions of WinRM that are compatible with various Windows operating systems, facilitating remote management capabilities across different platforms as listed in a table format.
4. **Command Line Utility**: Information on using tools such as wevtutil for obtaining detailed information about event logs and publishers is provided, enabling users to explore specific events related to security auditing.
5. **Event ID Mapping Across Versions**: A note is made regarding the transformation of security event IDs between Windows XP and newer versions of Windows, noting that this rule does not apply specifically to successful or failed logon events.
This document serves as a comprehensive guide for setting up and managing secure event collection across heterogeneous environments using Microsoft's recommended tools and methods as documented.
The document provides information about the Windows Remote Management (WinRM) version correlation with different operating systems, specifically highlighting support for Windows Server 2008 SP2. It outlines that WinRM versions are installed differently across various OS releases and specifies required .NET Framework versions where applicable. Table 17 lists the supported OS versions for each WinRM version update, including installation packages available through knowledge base articles.
Table 18 provides direct URLs to download the WinRM updates from Microsoft's support site based on the specific Windows release. It also notes that some updates include Release Notes. The document further explains default configuration settings of WinRM in Windows Server 2008 R2, which can be viewed and modified using a command line tool like PowerShell or by directly accessing the config settings via code or scripts.
The detailed breakdown includes protocol settings such as MaxEnvelopeSizekb (default is 150 kilobytes), MaxTimeoutms (default is 60000 milliseconds or 60 seconds), and MaxBatchItems (default varies between WinRM 1.1 and earlier versions with 20, and for WinRM 2.0 with 32000). Additionally, client configuration settings like NetworkDelayms (default is 5000 milliseconds), URLPrefix (default is 'wsman'), and AllowUnencrypted (defaults to false) are also detailed in Table 19, alongside their default values for each WinRM version.
This document provides an overview of the default configurations and settings for WinRM (Windows Remote Management) in Windows operating systems, including versions 1.1 and 2.0. The main points covered are:
**Default Ports:**
**WinRM 1.1 and earlier:** HTTP = 80, HTTPS = 443
**WinRM 2.0:** HTTP = 5985, HTTPS = 5986
**TrustedHosts:**
These hosts do not need to be authenticated for remote management.
**WinRM Client Configuration (Table 20):**
**Parameters and Descriptions:**
RootSDDL: Security descriptor for remotely accessing the listener.
WinRM 1.1 and earlier: O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GWGX;;;WD)
WinRM 2.0: O:NSG:BAD:P(A;;GA;;;BA)(A;;GR;;;ER)S:P(AU;FA;GA;;;WD)
MaxConcurrentOperations: Maximum number of concurrent operations (default varies).
MaxConcurrentOperationPer
This document discusses the registry keys and settings related to Windows Remote Management (WinRM) and Event Forwarding in Microsoft Windows. It covers security descriptor definition language (SDDL), which is used for customizing subscription targets, and troubleshooting WinRM issues using command line options. The registry keys include HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Listener, HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Plugin, and HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Service among others. SDDL is used to define access control for subscriptions targeting users, computers, or groups using SID values. Troubleshooting commands include winrm help, winrm id –remote:TARGET, winrm get wmi/root/cimv2/Win32_Service?Name=WinRM, and others.
To assist with the authentication process, WinRM offers various methods for remote management. The most recommended method is to use the `-remote` option along with the target hostname (local or remote). For instance, if the command is executed on a computer named ABCD using the command `winrm get winrm/config –remote:ABCD`, it requires an uninterrupted connection to the Domain Controller if the source is part of a domain.
When dealing with operational logs and troubleshooting issues, accessing Event Viewer or using tools like `wevtutil.exe` can be helpful. The locations for operational logs are typically under Applications and Services Logs in the Event Viewer:
Microsoft > Windows > EventCollector > Operational
Microsoft > Windows > Eventlog-ForwardPlugin > Operational
Microsoft > Windows > Windows Remote Management > Operational
For querying the Event Forwarding log, you can use `wevtutil` with specific parameters. For more information on capabilities and usage of `wevtutil`, run `wevutil /?`.
WinRM can generate several errors which are documented in tables that help identify common issues and their solutions. Event IDs associated with WinRM for Windows Vista and later versions can be found on Microsoft’s TechNet site. For example, during subscription creation, there might be errors like "The subscription is saved successfully, but it can't be activated at this time" or "Failed to open subscription." These could be due to firewall exceptions being disabled, the Event Collector not running, insufficient permissions, incorrect username/password, or Windows Firewall service not running.
For access denied errors in WinRM commands, ensure that users are part of local administration groups, passwords are provided correctly, and necessary permissions for secure connections are set. The article also mentions specific error codes (e.g., -2147024891) and their implications.
This text is about a feature in Microsoft Windows, specifically for systems running Vista and later versions, which involves an Event Forwarding Plugin that logs errors if certain XPath queries are incorrect when deployed to sources. The error is indicated by event ID 101 in the Operational log under "Eventlog-ForwardingPlugin" on these systems.
To diagnose the issue:
1. Locate the event with ID 101 within the specified operational logs.
2. Switch to the XML view of the details tab for that event.
3. Look for the "Status" data node, which contains a decimal value representing a Win32 error code. If this code is 15001, it signifies an invalid query, corresponding to ERROR_EVT_INVALID_QUERY in Windows Error Codes (MS-ERREF).
The information provided also includes references to various Microsoft documentation that could be useful for further understanding or resolution of these errors.
Comments