Windows Auditing 101
FREE ONLINE E-BOOK
You can click and start reading the chapters from below. We've also sent the
link to your inbox for future reference.
In 2019, it was reported that the Windows operating system was used on 72.1 percent of the servers worldwide. Most organizations today are predominantly Windows shop.
Windows auditing and log monitoring becomes inevitable when you want to ensure and maintain the cybersecurity posture of your network. However, this is often easier said than done.
In this vital resource, we'll elaborate on what you need to know about Windows auditing, including from login to what information you need to obtain from the logs, and how you can correlate the log details with other activities on your network to gain a holistic view of your security posture.
The basic Windows auditing policy specifies a set of security-related activities for evaluating critical events. In Windows, by default, the logging and auditing of events are disabled, but this auditing policy allows you to enable logging of certain events to gain visibility into the most common security activities happening in your network.
The following events are covered under the nine basic security auditing policies:
From the different events suggested, you can enable auditing for specific events depending on the security needs of your organization. We’ve curated some of the basic events and mapped them with the use case it can resolve.
Intruders and impostors want to stay inside the network unnoticed. They try to cover up traces of their malicious operations and lateral movements. However, if you monitor closely, you can differentiate the trace deletions from legit actions. We recommend you enable auditing for these events and inspect them regularly to uncover threat actors in your network:
Look for the user account from which the logs were cleared. Gathering and investigating all the activities done by that user account will add more contextual data to evaluate the audit log clearance and help you determine if it's a legitimate activity or not.
Unless this is a planned event for maintenance, it can indicate a possible cyberattack.
Tip: To gain clear and better visibility, look for the account which performed this operation (Event ID 4624) and from which machine the service was shut down. This gives you additional information that will help you differentiate the legitimate operation from the suspicious ones.
Use a security information and event management (SIEM) solution to collect, archive, and encrypt logs periodically. Centralized log collection also makes it easier to correlate and analyze the events happening in your network. Effective Windows log management also helps in resolving operational issues and troubleshoot critical failures.
Monitoring login activities can provide information on the anomalous activities happening within the network. For instance, User A logging in after work hours and trying to access protected information is subject to investigation. Multiple logins from the same account, a large number of login failures, and account lockouts are all common examples of unusual account activities. To monitor the login activities, enable auditing for these events:
The mode of logging in can give you clues to check the legitimacy of the attempt.
Monitor the Logon Type field for categories 3, 4, 5, 8, 9, and 10.
This event id is generated after every failed attempt regardless of the logon type. So you can easily check the type of logon used to access the system or resources. A massive spike in failure events within a short span may indicate a possible brute-force attack.
This happens when the user or attackers uses too many wrong passwords. Such events should always be followed up to check if it was legitimate.
Use a security tool to analyze the logon trends and user behaviors.Setup alerts to capture unusual logins including logins outside business hours, unusual volume of login failures and more. Most often, enterprises use a rule-based threat detection technique to spot malicious activities. However, the accuracy of differentiating a legitimate event from a suspicious one is relatively less in a rule-based or signature-based threat detection technique.
We recommend using a SIEM that has a built-in machine-learning based behavioral analytics component. User and entity behavior analytics (UEBA) modules use machine-learning techniques to baseline normal behaviors and then detect outliers. Often, they are also associated with risk management systems to validate the impact of a threat and reduce false positives to a greater extent.
For example, when Mark from the marketing department tries to access financial data, which he has never accessed, a high-risk score alert will be triggered, indicating a possible malicious action. By combining UEBA with automated incident response capabilities, you can take corrective actions such as restricting access to the user, or locking out the system.
Attackers may try to modify the registry values to launch a malicious application or service during system startup. They can sometimes replace a whole registry or a particular key value in it to achieve this. One such example is the password filter DLL attack, where the hacker injects a malicious DLL file in the HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ Lsa -> Notification Packages registry.
Monitoring registry changes lets you:
Here's a critical registry change event that you need to enable and monitor:
Enable registry auditing and alerting on systems containing high-value data, domain controllers, and servers. Take regular backups of the registries in case anything goes wrong.
Tip: When registry changes are followed by an attempt to access an object (Event ID 4663), or a successful logon (Event ID 4624) to an unusual resource, it could be a potential threat. Use your security solution to correlate registry changes with critical follow-up actions to spot threats early and stop them from causing damage.
Make sure registry permissions are set for Administrators only and monitor key registries for malicious actions.
Brute force is a technique used by adversaries trying to input hundreds and thousands of username and password combinations within a short period, hoping to get one right. There are lots of tools to automate this process. With the help of these Windows events, you can perform basic brute force attack detection.
To spot brute-force attacks, look for multiple logon failures within a short period, and at least one successful logon from the same source.
Tip: Though signature-based brute force detection is helpful, it can be misleading and provide false alarms. Advanced behavioral analytics powered by machine-learning techniques can accurately spot unusual volume of logon failures baselining with regular activity. When coupled with automatic remediation responses, it can immediately take corrective actions, such as locking the system or cutting off communication from malicious sources, thus saving time and preventing damage.
This happens when the user or attackers uses too many wrong passwords.
Tip: Look for the user account from which multiple login attempts were made (Event ID 4624). This can help you find which account was compromised, the permissions that the account has, etc. Using this you can restrict access permissions to the compromised account before major damage.
Immediately reset the password for the compromised host. Check for traces where the same username was used to log on within the network.
Adjust the threshold if you have a single point of authentication.
When adversaries gain access to your network, they want to drop malware packages like ransomware, or exfiltrate sensitive data and sell it on the dark web. A sudden spike in access requests to certain databases may indicate a potential breach. These are some of the events that you must log and audit to spot suspicious file and folder changes:
This event id is generated when an object is accessed. The object can be a file, kernel system, registries, or files present on a removable disk. It is recommended that you set alerts to determine if anyone tries to access any object in protected servers.
Tip: Hackers will attempt other attacks if they don't get what they want. To thwart them, correlate the Handle ID of Event ID 4656 to detect subsequently audited events while the object is open. You can also detect the attackers' attempts to drop malicious packages inside critical folders by monitoring anomalous process creations (Event ID 4688).
Utilize File Integrity Monitoring (FIM), a critical capability that can detect changes to files and folder permissions, and spot unusual accesses to protect sensitive data from being stolen or leaked.SIEM solutions come with this built-in capability. If your organization is storing or processing sensitive data at large volumes or is liable to comply with any of the regulatory mandates, such as PCI-DSS, HIPAA, GDPR, and others, we recommend you to go for the tool with embedded FIM capability to protect your network from security breaches.
Monitoring the traffic from and to the network adds contextual information to your threat hunting process. Connection details available in log data such as the source IP address and its location provide clear visibility of what's happening in your network when trying to detect security threats or attack attempts. When this information is correlated with other events, it helps you to identify the compromised systems, lateral movement of adversaries, malicious packages that are dropped into your network, and more. Therefore, it becomes essential for you to log and closely monitor the inbound and outbound connections. These are some of the events that you must log to conduct security auditing:
This event id is generated whenever the Windows Filtering Platform allows an inbound or outbound connection. Since this is a high-volume event, we recommend auditing only if every network connection to a server or application needs to be tracked. For example, a browser connecting to the internet versus PowerShell making an outbound connection.
When a connection from or to a malicious source is being established, it should be immediately cut-off. To do this, you need a list of blacklisted IP addresses, URLs, and domains. Unfortunately, such threat feeds are dynamic and constantly changing.
The ideal way is to either have a built-in threat intelligence platform in a SIEM tool or to integrate your security solution with a third-party threat intelligence platform. These threat intelligence solutions have a list of all blacklisted and malicious sources that are updated dynamically. Further, they also provide you with a reputational score that helps you determine the trustworthiness of a site, geo-location of a malicious source, and more.
Windows Advanced Auditing Policy overlaps with the basic Windows auditing policies stated above. However, these are recorded and applied differently. Advanced auditing empowers administrators to be more selective in the number and types of events to audit.
For instance, if you enable success auditing for the basic Audit account logon events, success events for all account logon-related behaviors will be logged. However, with advanced auditing policy, administrators can select only the behaviors they want to monitor and exclude audit results for behaviors that are not important. Administrators can enable success events for one subcategory of account logon category, failure events for another subcategory, and choose to not audit the rest of the subcategories. Such granular control over audit policy largely reduces noise and false positives while spotting security threats.
We've mapped a few events that you need to monitor and that fall under the advanced auditing policy, with the security use case it can detect.
An attacker will not always end up with an account with higher levels of access. So they will try to elevate the level of access of any account they get their hands on. They also try to access privileged user accounts to take control of the entire network. Therefore, we need to monitor for unauthorized privilege access attempts.
Analyzing the following events will provide insights into privilege abuses.
This event id is generated when SeSystemtimePrivilege, SeCreateGlobalPrivilege, or SeTcbPrivilege is called. You can have a list of allowed and denied user rights or process names and trigger alerts for misuse of "Privileges" and "Process Name" fields.
Monitor this event with the “Subject\Security ID” or “Account Whose Credentials were Used\Security ID” that correspond to the accounts that indicate malicious actions.
Tip: Correlate the account which was used to login (Event ID 4624) to the critical system. In certain situations, the user will be required to enter the admin credentials (Event ID 4648) while running a program, or when batch-type configurations such as scheduled tasks are executed.
You should also check if the user has logged in outside the authorized hours or used an unauthorized workstation to do it (Event ID 4776).
Correlate the file and folder changes (Event ID 4663) which are immediately followed by privileged access attempts.
You can use these event ids to track pass-the-hash attacks. But it is not easy to detect lateral movement from such attacks. A SIEM solution with UEBA capabilities can correlate many events to keep a risk score of the accounts in the network. When the set threshold value is reached, alerts will be raised.
In Kerberoasting attacks, the service account credential hashes are extracted from Active Directory for offline cracking. This attack is very effective when people create poor passwords.
Every Kerberos ticket is stored with AES128-CTS-HMAC-SHA1-96 encryption (from Windows Server 2008 and Vista). Attackers request Kerberos service tickets which are then exported for decryption. Different New Technology Local Area Network Manager (NTLM) hashes are used to do this, and once the ticket is successfully opened, the correct service account password is discovered.
Attackers may request hundreds of service tickets hoping to find the password in any one of them. So lookout for a spike in requests for service tickets.
Use the following filters to reduce noise
This event is generated every time the key distribution center fails to issue a Kerberos ticket-granting ticket (TGT). Look for mass records of Failure code 0x18 which could indicate possible Kerberos spraying.
1. Strengthen passwords: Implement a strong password policy in your organization, especially for service accounts.
2. Deploy honeypots: You can set traps with honey accounts to serve as decoy targets for attackers, and trigger alerts when they are used to generate a service ticket.
3. Continuously monitor: Monitor the service accounts for anomalous activity. UEBA uses machine learning to keep track of the risk score or all the objects in your network. When the threshold is reached, alerts will be triggered instantly so that you can respond immediately.
Sometimes rogue employees might try to steal information using external storage devices. The main purpose of USB device analysis is to identify the devices connected to your network and monitor the usage metrics—files copied to or from the device, connection time, etc.
This event id can be used in servers or networks where important information is stored. Set alerts for this event whenever the Subject\Security ID field is not SYSTEM.
Tip: Watch out for changes in the following registry and values (Event ID 4657):
Log successful attempts to write to or read from an external device (Event ID 4663).
Since this event is used to track anomalous usage of external devices, a SIEM tool with UEBA functionalities can be used to detect malicious behavior. This feature correlates several events to keep a risk score of the objects in the network. When the set threshold value is reached, alerts will be raised.
Malwares use scheduled tasks to perform malicious actions after they enter the network. They are also used to maintain a presence in the network by installing backdoors or remote access tools to enter effortlessly after every reboot.
Tip: Monitor the Task Scheduler Library root node for new tasks and raise an alert if the Task Content: XML contains <LogonType>Password<LogonType> value. This code can be used by attackers to extract the password of the account with which the scheduled task was created.
Every malware can execute a code by creating a new process, once it's inside the network. This process will automatically launch depending on the attack type (sometimes days or months after infiltration).
By tracking this event id 4688, you can trace the instances of the malware processes, and find possible spreading to other devices in the network.
This event id lets you capture unauthorized processes that change registry values and spot malware activity or suspicious changes to key registry values. Enable auditing and alerting on systems containing high-value data, domain controllers, and servers. Take regular backups of the registries in case anything goes wrong. Know more about tracking registry modifications.
Correlating multiple events can help you better understand the whole idea behind the attack. It's also impossible to review and analyze large amounts of data without a centralized logging solution. We recommend you use a SIEM tool that centrally collects the logs to make it easier for defenders to perform mitigation activities easily.
Most users log in to one or two systems during a typical day. But user accounts that try to log in from different machines may indicate compromise. Remote logins can indicate possible lateral movement.
Monitor the Logon Type field for categories 2,3,9, and 10.
2 - Interactive Login: Indicates a user logged into the system by using the keyboard.
3 - Network: The user has logged in to the computer from somewhere else within the network.
9 - New credentials: The user could have used different credentials to access any sensitive areas or execute admin-level commands (Runas) on the computer.
10 - Remote Interactive: Indicates that the logon was through Terminal Services or Remote Desktop.
Monitor and raise an alert for this event in case the unique machine logon is greater than the set threshold value. Restrict login permission from other machines that try to log in if it exceeds more than the set value.
Sysmon (System Monitor) is a Windows system service and device driver that comes as a part of Windows Security utlities and logs events to Windows event logs. Sysmon logs provide information on process creation, network connection, and changes to file creation time.
Some Sysmon log information and regular Windows event information overlap. However, Sysmon logs possess below additional information that differentiates it in security auditing.
As you can see, Sysmon logs provide critical details that help you to hunt down security threats effectively and proactively.
Below, we'll look at what kind of threats can be detected or prevented by monitoring specific Sysmon events.
Tip: Sysmon logs can be found in the Sysmon folder: Applications and Services Logs > Microsoft > Windows > Sysmon.
Sysmon doesn't have built-in analytics capabilities. All it does is generate logs for specific events. You need a security information and event management (SIEM) solution or at the minimum a Windows event collection and analysis tool to get actionable insights from Sysmon logs.
Phishing is one of the most commonly used techniques to break into a corporate network. Phishing scams are often used to drop malicious programs in the network that can cause data breaches or launch ransomware attacks.
Attackers may send bulk emails to employees to trick them into initiating malicious processes. Once the process or task is created, the attacker can compromise accounts, exfiltrate data, or laterally move within the network to exploit other systems. Sysmon analysis helps spot and contain malware at the earliest stages.
Just like Windows event ID 4688, Sysmon event ID 1 tracks all the newly created processes along with when they are terminated. But this Sysmon event gives you more information on the parent process ID, location of the parent process, and more. This helps with tracking the process hierarchy, which comes in handy during forensic investigations.
Attackers send malicious files or links in the emails that can download payload data onto your systems when executed. This payload can then be used to:
The most critical resources needed for a system to function properly are stored in the C drive. Attackers can drop malware in this drive, so that it gets loaded along with the boot files during startup.
This event detects file creation in places inside the C drive, like temporary, and download folders where malware can be configured to create files when needed.
Each downloaded file from the web is tagged with a Zone.identifier tag by the browser. This tag contains information on the zone from which the file originated and the URL from which it was downloaded.
The Zone ID values indicate different sources, such as:
This information can be used to trigger security responses on the downloaded files.
Event ID 15 is generated whenever a file stream is created and contains the following data:
Tools such as Mimikatz are used by malicious actors to extort credentials from the memory. These tools can extract passwords, hashes, Kerberos tickets, and more.
When installed into your system, the tool (Mimikatz), which is started as a process, accesses credential storage areas such as lsass.exe to dump the credentials. It is difficult to detect such activities with Windows log auditing because the parent process isn't known. Therefore, Sysmon analysis provides better visibility and helps connect different events to stop the attackers at their initial stages.
Set the TargetImage=C:\Windows\system32\lsass.exe in the config.xml file to detect when any process tries to access lsass.exe.
Look for Sysmon logs with the event ID 10.
Attackers may try to modify the registries to launch a malicious application or service during system startup. They can sometimes modify a whole registry or a particular key value in it to achieve this. One such example is the password filter DLL attack, where the hacker injects a malicious DLL file in the HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ Lsa > Notification Packages registry.
So, you need to monitor registry changes as they can help you:
Here are some sysmon events that you need to monitor:
This event tracks the key and value creation or deletion operations of specific registries.
This event ID tracks registry value changes made by attackers.
This event tells you when the registry keys and values are renamed along with the new name given to it.
Tip: Combining the Sysmon events with Windows events can help you detect if the attacker attempts to access an object (4663) or tries to log in (4624) to an unusual resource. These events can indicate a potential threat if followed by registry modification.
Attackers may use the application layer protocols to avoid detection by blending in with regular traffic. Using these protocols they can send commands to the Command and Control servers to drop payloads or exfiltrate data. One of the places you need to monitor for anomalous behavior is DNS traffic.
This event ID is generated whenever a process executes a DNS query. You can use this event ID to check the process origin and the final query executed by the process. This event ID is supported only on Windows 8.1 and later.
This event ID is generated whenever there is a TCP/UDP connection on the machine. You can use both Event ID 22 and 3 to check for DNS queries.
This event ID gives you information on the image being used, port name, and destination address. For example, if you see a process accessing a server using an SSH port, it could be malicious.
Tip: For more context, correlate event IDs 22 and 3 with the following event.
This event can be correlated with event ID 22 to see the name of the file they downloaded and the source URL. The hash provided from this event ID can be used to check if the same operation was done on any other system in the network.
Detecting lateral movements in your network can be a challenging task. When attackers gain admin privileges, it becomes especially difficult to differentiate malicious actions from legitimate ones. With a SIEM solution capable of Sysmon monitoring, you can quickly detect attempts to move laterally.
Once the attacker gains access to a host, they can spread malware to other devices by using trusted Windows tools like PsExec. They might also change the name of the executable to evade detection. For example, they can rename their executed process to PsExec.exe, which will remain undetected if you had set alerts for the original process name.
Event ID 1 retains the original metadata (OriginalFileName) of the executable to give you the opportunity to get alerts upon attempts to evade detection by renaming processes.
Attackers may try to connect to critical servers once they get access to a system in the network. A standard user trying to connect to a server to which they don't have access is a suspicious event. This event ID tracks all the TCP/UDP connections on the machine. Using the source and destination hostnames and IP addresses, you can find out which system was compromised.
Tip: Correlating the above mentioned events with Windows event ID 4624 can help you detect the account that was used to log in. In some cases, the attacker would've been required to explicitly enter the credentials (event ID 4648) to execute a process.
You can also implement a SIEM tool with UEBA capabilities to detect lateral movement. UEBA tracks the activity of each user object in your environment to assign risk scores. Alerts will be raised when the set risk score is reached.
Attackers have been using techniques like process hollowing and herpaderping to execute malicious code masked under legitimate processes.
Process Hollowing - A technique that deallocates legitimate code in a trusted Windows process and then replaces it with a malicious code when needed. This malicious code will now run under a legitimate Windows process.
Process Herpaderping - This is a technique where the contents of the process are modified after the image is mapped. This makes the process appear harmless to the user while a malicious process runs in the memory. For example, Mimikatz can be executed under chrome.exe, making it appear to the OS that a trusted process is running with a valid Google signature.
Process hallowing has been around for years. But herpaderping is a relatively new and powerful approach used to remain undetected if auditing is not enabled.
This event detects the process hiding techniques explained above. The Image field in this event ID gives you info on the process that was tampered with.
We recommend forwarding this event to a SIEM tool that can correlate many events to give you info on who performed the attack and how far it has spread in the network.
Since Sysmon auditing is noisier than Windows auditing, it's a best practice to decide on the files and folders you want to include and exclude from monitoring, and keep the file length to a minimum. This reduces management issues and helps you collect only the things you really need. This event filtering is done using the config.xml file.
When an intruder gains access to this configuration file, they can easily find out the places you are monitoring and exploit someplace you're not. So, you should monitor these registry keys and files for suspicious changes:
Tip: Don't forget to change the default name of the config.xml file and move it from the default location (C:\Windows).
Sysmon does not register events when key values in the registries mentioned above are changed. To report such changes, Windows Security event ID 4657 must be used.
The registry in Windows is like the CPU in a computer: You know why it's there and what it does. But if something goes wrong, you don't attempt to fix it unless you're sure how to do it.
A registry is an internal database that consists of the settings necessary for Windows applications to function properly. Adversaries can use the registry to maintain a presence in your network, and one of the simplest ways they do that is by adding malicious applications to your startup folder. They might also try to modify the values in the registry to execute malicious packages dropped off in the system.
By auditing the registry, you can help prevent the persistence of malware in your system.
Monitoring the registry lets you:
Let's look at some use cases that show how to detect modifications to registry keys or their values, and our recommendations for mitigation.
When adversaries gain initial access, the first thing they want to do is drop malware packages in your system. These malware packages are usually dropped in the startup folder of the system (C:\Users\[User Name]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup) so the package reloads every time the user logs in.
The following registry keys control the automatic startup of services during boot:
Registry changes can also happen under normal circumstances. So, monitor them for suspicious changes that don't correlate with any updates, network-wide changes in policies, application installs, and other known network activities.
Rogue employees may try to steal information using external storage devices. USB device analysis helps to identify the devices connected to your network and monitor usage metrics like files copied to or from the device and connection time.
Whenever new USB devices are plugged in, the information about the devices is stored in the following registry keys:
These registry keys help you identify the vendor, product, and version of the USB device.
When combined with Windows event ID 4663, you can see successful attempts to write or read from an external device. Event ID 4624 lets you find the user who used the device.
We recommend using a SIEM tool with UEBA capabilities to detect malicious behavior in your network. You can correlate multiple events to keep a risk score for each object. When the set threshold value is reached, alerts will be triggered.
Root certificates are public key certificates that are commonly used by browsers to establish a secure TLS/SSL communication with a website. Usually when a user tries to connect to a website that doesn't support a trustable certificate, a warning is displayed.
Malicious actors can install a custom root certificate on a compromised system to persist in the network. Since the system or application trusts all the certificates presented in the root's chain of trust, adversaries can easily connect to a command and control (C2C) server without triggering a security warning.
All root certificates are added in the following registry keys:
They're also in registry keys containing the following:
Tip: You can also use Sysmon IDs 12, 13, and 14 to write scripts that trigger an event if the keys mentioned above are modified.
Winlogon is a critical component of Window systems that's responsible for handling the secure attention sequence (Ctrl+Alt+Del), which ensures you're logging on to a secure desktop and no other software can monitor your keyboard activity while typing in your password. This component is also responsible for loading your user profile during logon, shutting down your system, locking your screen due to inactivity, controlling the actions that happen when a user logs on, and more.
Adversaries can use certain features of Winlogon to execute malicious code into your system to establish persistence, so it's crucial to monitor the registry keys that define which processes start during a Windows logon.
Monitor suspicious changes in the following registry keys:
Attackers will drop malicious executables in the System32 folder and modify any of the registry keys mentioned above to include and run the payload during Windows logon.
Every time a user raises a password change request, the local security authority calls the password filters to validate them against a predefined policy to prevent the use of weak passwords.
Adversaries can install a malicious password filter DLL file into the domain controller to capture clear text passwords and pass them on to their C2C server.
This attack requires the adversary to place the malicious DLL file in the System32 folder and replace the DLL filename in the following registry key:
So, monitor this registry key for suspicious modifications.
Tip: A file addition event in the %windir%\system32\ folder followed by registry modification and a notification package loading event can indicate a possible password filter DLL attack.
We recommend using a SIEM solution that comes with a prebuilt correlation engine to correlate the Object Name (4657) and the Notification Package Name (4614) to detect anomalous changes and raise alerts.
ManageEngine Log360, a comprehensive SIEM solution, helps enterprises to thwart attacks, monitor security events, and comply with regulatory mandates.
The solution bundles a log management component for better visibility into network activity, and incident management module that helps quickly detect, analyze, prioritize, and resolve security incidents. Log360 features an innovative ML-driven user and entity behavior analytics add-on that baselines normal user behaviors and detects anomalous user activities, as well as a threat intelligence platform that brings in dynamic threat feeds for security monitoring.
Log360 helps ensure organizations combat and proactively mitigate internal and external security attacks with effective log management and in-depth AD auditing.Download Request for a personalized demo
We regularly update this guide with new information and multimedia content. We ask for your information so we can notify you about updates via email.
We'll also send you important Windows-security-related information when a critical vulnerability is identified.
You don't have to provide your email address to access this guide every time; instead, bookmark the page and revisit it anytime while configuring security policies in your organization.
This guide contains over 15 critical Windows auditing use cases that demonstrate configurations you may have missed.
You'll receive a 45-day, complimentary license for Log360
© 2021 Zoho Corporation Pvt. Ltd. All rights reserved.