Microsoft Windows Security Event Log
The JSA DSM for Microsoft Windows Security Event Log accepts syslog events from Microsoft Windows systems. All events, including Sysmon and Winlogbeat.json, are supported.
For event collection from Microsoft operating systems, JSA supports the following protocols:
-
Syslog (Intended for Snare, BalaBit, and other third-party Windows solutions)
-
Forwarded.
-
TLS Syslog.
-
TCP Multiline Syslog.
-
Microsoft Event Log (WMI). See Juniper Secure Analytics Vulnerability Manager User Guide.
-
Windows Event Log Custom (WMI). See Juniper Secure Analytics Vulnerability Manager User Guide.
-
MSRPC (Microsoft Security Event Log over MSRPC).
-
WinCollect. See the Juniper Secure Analytics WinCollect User Guide.
-
WinCollect NetApp Data ONTAP. See the Juniper Secure Analytics WinCollect User Guide.
-
Amazon Web Services protocol from AWS CloudWatch.
Ensure that you have an Azure storage account and an Azure event hub.
-
Optional: Create a storage account.
Note:You must have a storage account to connect to an event hub.
-
Optional: Create an event hub.
Installing the MSRPC Protocol on the JSA Console
You must install the MSRPC protocol RPM on the JSA console before events can be collected from a Windows host.
Ensure that you download the MSRPC protocol RPM from the Juniper Downloads onto your JSA Console.
-
Log in to the JSA console as a root user.
-
Copy the MSRPC protocol RPM to a directory on the JSA console.
-
Go to the directory where you copied the MSRPC protocol RPM by typing the following command:
cd <path_to_directory>
-
Install the MSRPC protocol RPM by typing the following command:
yum –y install PROTOCOL-WindowsEventRPC-<version_number>.noarch.rpm
-
From the Admin tab of the JSA console, select Advanced >Deploy Full Configuration.
-
After you deploy the configuration, select Advanced >Restart Web Server.
MSRPC Parameters on Windows Hosts
To enable communication between your Windows host and JSA over MSRPC, configure the Remote Procedure Calls (RPC) settings on the Windows host for the Microsoft Remote Procedure Calls (MSRPC) protocol.
You must be a member of the administrators group to enable communication over MSRPC between your Windows host and the JSA appliance.
Based on performance tests on an JSA Event Processor 1624 appliance with 128 GB of RAM and 40 cores (Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80 GHz), a rate of 8500 events per second (eps) was achieved successfully, while simultaneously receiving and processing logs from other non-Windows systems. The log source limit is 500.
|
Specification |
Value |
|---|---|
|
Manufacturer |
The operating system dependant type of the remote procedure protocol for collection of events. Select one of the following options from the Protocol Type list:
|
|
Supported versions |
Windows Server 2016 Windows Server 2012 (most recent) Windows Server 2012 Core Windows Server 2008 (most recent) Windows Server 2008 Core Windows 10 (most recent) Windows 8 (most recent) Windows 7 (most recent) Windows Vista (most recent) |
|
Intended application |
Agentless event collection for Windows operating systems that can support 100 EPS per log source. |
|
Maximum number of supported log sources |
500 MSRPC protocol log sources for each managed host (16xx or 18xx appliance) |
|
Maximum overall EPS rate of MSRPC |
8500 EPS for each managed host |
|
Special features |
Supports encrypted events by default. |
|
Required permissions |
The log source user must be a member of the Event Log Readers group. If this group is not configured, then domain admin privileges are required in most cases to poll a Windows event log across a domain. In some cases, the Backup operators group can also be used depending on how Microsoft Group Policy Objects are configured. Windows XP and 2003 operating system users require read access to the following registry keys:
|
|
Supported event types |
Application System Security DNS Server File Replication Directory Service logs |
|
Windows service requirements |
For Windows Server 2008 and Windows Vista, use the following services:
For Windows 2003, use the Remote Registry and Server. |
|
Windows port requirements |
Ensure that external firewalls between the Windows host and the JSA appliance are configured to allow incoming and outgoing TCP connections on the following ports: For Windows Server 2008 and Windows Vista, use the following ports:
For Windows 2003, use the following ports:
|
|
Automatically discovered? |
No |
|
Includes identity? |
Yes |
|
Includes custom properties? |
A security content pack with Windows custom event properties is available on https://support.juniper.net/support/downloads/. |
|
Required RPM files |
PROTOCOL-WindowsEventRPC-JSA-version-Build_number.noarch.rpm DSM-MicrosoftWindows-JSA-version-Build_number.noarch.rpm DSM-DSMCommon-JSA-version-Build_number.noarch.rpm |
|
More information |
|
|
Troubleshooting tool available |
MSRPC test tool is part of the MSRPC protocol RPM. After installation of the MSRPC protocol RPM, the MSRPC test tool can be found in /opt/ qradar/jars |
Microsoft Security Event Log over MSRPC log source parameters for Microsoft Windows Security Event Log
If JSA does not automatically detect the log source, add a Microsoft Windows Security Event Log log source on the JSA Console by using the Microsoft Security Event Log over MSRPC protocol.
When using the Microsoft Security Event Log over MSRPC protocol, there are specific parameters that you must use.
The following table describes the parameters that require specific values to collect Microsoft Security Event Log over MSRPC events from Microsoft Windows Security Event Log:
|
Parameter |
Value |
|---|---|
|
Log Source type |
Microsoft Windows Security Event Log |
|
Protocol Configuration |
Microsoft Security Event Log over MSRPC |
|
Log Source Identifier |
Type the IP address or host name for the log source as an identifier for events from your Microsoft Windows Security Event Log devices. |
Diagnosing Connection Issues with the MSRPC Test Tool
Use the MSRPC test tool to check the connection between the JSAappliance and a Windows host.
Ensure that the PROTOCOL-WindowsEventRPC- <version_number> is installed on the JSA appliance.
The MSRPC test tool can be used for troubleshooting connection problems and to test the initial connection between the host and the JSA appliance to ensure that the host is configured properly. Table 1 describes the MSRPC test tool option flags.
|
Flags |
Description |
|---|---|
|
-? or --help |
Displays the help and usage information for the MSRPC tool. |
|
-b |
Displays debugging information, if available. |
|
-d <domain> |
Active Directory Domain, or hostname if in a workgroup. |
|
-e <protocol> |
EventLog Remoting protocol. Values: MSEVEN, MSEVEN6, and AUTO Default: AUTO |
|
-h <hostname/ip> |
Hostname or IP address of the Windows host. |
|
-p <password> |
Password |
|
-u <username> |
Username |
|
-w <poll> |
Polling mode. Specify one or more event log channels. Values: Security, System, Application, DNS Server, File Replication Service, Directory Service Separate multiple values by comma. Example: Application, Security. Default: Security |
-
Log in to the JSA console.
-
To use the MSRPC test tool, type the following command:
cd /opt/qradar/jars
-
To test for connection between the JSA and the Windows host, type the following command:
java -jar Q1MSRPCTest.jar
-
Optional: For more usage options, type java -jar Q1MSRPCTest.jar --help
WMI Parameters on Windows Hosts
To enable communication between your Windows host and JSA, you can use Windows Management Instrumentation (WMI).
You must be a member of the administrators group on the remote computer to configure WMI/DCOM Windows host and the JSA appliance.
The Microsoft Security Event Log protocol (WMI) is not recommended for event collection where more than 50 EPS is required or for servers over slow network connections, such as satellite or slow WAN networks. Network delays that are created by slow connections decrease the EPS throughput available to remote servers. Faster connections can use MSRPC as an alternative. If it is not possible to decrease your network round-trip delay time, we recommend that you use an agent, such as WinCollect.
|
Specification |
Value |
|---|---|
|
Manufacturer |
Microsoft |
|
DSM name |
Windows Security Event Log |
|
Supported versions |
Windows Server 2016 Windows 2012 (most recent) Windows Server 2012 Core Windows Server 2008 (most recent) Windows 10 (more recent) Windows 8 (more recent) Windows 7 (most recent) Windows Vista (most recent) |
|
Special features |
Supports encrypted events by default. |
|
Intended application |
Agentless event collection for Windows operating systems over WMI that is capable of 50 EPS per log source. Note:
This is a legacy protocol. In most cases, new log sources should be configured by using the Microsoft Security Event Log over MSRPC protocol. |
|
Special configuration instructions |
Configuring DCOM and WMI to Remotely Retrieve Windows 7 Events (http://www.ibm.com/support/docview.wss?uid=swg21678809) Configuring DCOM and WMI to Remotely Retrieve Windows 8 and Windows 2012 Events (http://www.ibm.com/support/docview.wss?uid=swg21681046) |
|
Windows port requirements |
You must ensure that external firewalls between the Windows host and the JSA appliance are configured to allow incoming and outgoing TCP connections on the following ports:
|
|
Windows service requirements |
The following services must be configured to start automatically:
|
|
Log source permissions |
The log source user must be a member of the Event Log Readers group. If this group is not configured, then domain admin privileges are required in most cases to poll a Windows event log across a domain. In some cases, the Backup operators group can also be used depending on how Microsoft Group Policy Objects are configured. The log source user must have access to following components:
|
|
Supported event types |
Application System Security DNS Server File Replication Directory Service logs |
|
Automatically discovered? |
No, manual log source creation is required |
|
Includes identity? |
Yes |
|
Includes custom properties? |
A security content pack with Windows custom event properties is available on IBM Fix Central. |
|
Required RPM files |
PROTOCOL-WinCollectWindowsEventLog- JSA_release-Build_number.noarch.rpm DSM-MicrosoftWindows-JSA_release-Build_number.noarch.rpm DSM-DSMCommon-JSA_release-Build_number.noarch.rpm |
|
More information |
Microsoft support (support.microsoft.com/) |
|
Troubleshooting tools available |
Yes, a WMI test tool is available in /opt/qradar/jars. |
Microsoft Security Event Log Log Source Parameters for Microsoft Windows Security Event Log
If JSA does not automatically detect the log source, add a Microsoft Windows Security Event Log log source on the JSA Console by using the Microsoft Security Event Log protocol.
When using the Microsoft Security Event Log protocol, there are specific parameters that you must use.
The following table describes the parameters that require specific values to collect Microsoft Security Event Log events from Microsoft Windows Security Event Log:
|
Parameter |
Value |
|---|---|
|
Log Source type |
Microsoft Windows Security Event Log |
|
Protocol Configuration |
Microsoft Security Event Log |
|
Log Source Identifier |
Type the IP address or host name for the log source as an identifier for events from your Microsoft Windows Security Event Log devices. |
|
Domain |
Type the domain of the Windows system. |
Installing Winlogbeat and Logstash on a Windows Host
To retrieve Winlogbeat JSON formatted events in JSA, you must install Winlogbeat and Logstash on your Microsoft Windows host.
Ensure that you are using the Oracle Java Development Kit V8 for Windows x64 and later.
-
Install Winlogbeat 7.7 by using the default values. For more information, see Getting Started With Winlongbeat.
-
Start the Winlogbeat service.
Note:For Windows services, the service name is winlogbeat. After installation, the service is set to STOPPED, and then must be started for the first time. Any configuration changes beyond this point require a service restart.
-
Optional. For more flexibility when you configure Winlogbeat, see Set up Winlongbeat.
-
Install Logstash by downloading the package and saving it to a file location of your choice.
-
To ensure that Winlogbeat communicates properly with JSA, see Configure Winlogbeat to use Logstash.
The following basic sample configuration file can be used in the <logstash_install_directory>/
configfile.input { beats { port => 5044 } } output { tcp { host => ["172.16.199.22"] port => 514 mode => "client" codec => "json_lines" } stdout { codec => rubydebug } }Note:If you are using rubydebug, debugging must be enabled in the logstash.yml file. Uncomment the line
# log.level: info, and replaceinfowithdebug. Restarting the service is required after any configuration changes.Note:The
codecin output must be set tojson_linesto ensure that each event is sent separately to JSA.Note:If you want to send Kafka output to an existing Kafka server, see Configure the Kafka output.
-
Ensure that Logstash is set up correctly by verifying that the
configfile for Logstash is working. Run the following command from the Logstashbindirectory:logstash --config.test_and_exit -f <path to config file>
-
Ensure that Winlogbeat is configured correctly.
-
Verify that the config file is working by running the following command from the
winlogbeatdirectory:./winlogbeat test config
-
-
Verify that Winlogbeat can access the Logstash server by running the following command from the
winlogbeatdirectory:./winlogbeat test output
If the output of the
./winlogbeat test outputcommand is successful, it might break any existing connection to Logstash. If the connection breaks, restart the Logstash service.
Microsoft Windows Security Event Log log source parameters
When you add a Microsoft Windows Security Event Log log source on the JSA Console by using the Syslog protocol, there are specific parameters you must use.
The following table describes the parameters that require specific values to collect Syslog events from Microsoft Windows Security Event Log:
|
Parameter |
Value |
|---|---|
|
Log Source type |
Microsoft Windows Security Event Log |
|
Protocol Configuration |
Syslog |
|
Log Source Identifier |
The host ID of the logstash server. |
Configuring which usernames JSA considers to be system users in events that are collected from Microsoft Windows Security Event Log
By default, all user names in Microsoft Windows Security Event Log events that end with a dollar sign ($) are considered as system users and are excluded from event parsing. If you want to change the way that JSA parses events, you can use the DSM Editor to include system users.
-
Click the Admin tab.
-
In the Data Sources section, click DSM Editor.
-
From the Select Log Source Type window, select Windows Security Event Log from the list, and click Select.
-
On the Configuration tab, set Display DSM Parameters Configuration to on.
-
From the Event Collector list, select the event collector for the log source.
-
If you want usernames that end with a dollar sign ($) to always be considered as system users, set the System User Criteria parameter value to Usernames Ending With A Dollar Sign Are Considered As System Users.
-
If you want usernames that end with a dollar sign ($) as system users only when they match with the computer name, set the System User Criteria parameter value to Usernames Ending With a Dollar Sign If It Matches Computer Name Are Considered As System Users.
Tip:A username is considered to match the computer name when the username (excluding the dollar sign) is equal to the computer name or, if the computer name is a fully-qualified domain name, the host component of the computer name. Letter case is ignored. For example, if the username is HOST$ and the computer name is host or host.example.com, then the username is considered to match the computer name.
-
If you want usernames that end with a dollar sign ($) to never be considered as system users, set the System User Criteria parameter value to Usernames Ending With a Dollar Sign Are Not Considered As System Users.
-
Click Save and close out the DSM Editor.
Tip:If the Include System User With (No) Identity parameter value is set to Include System User With No Identity or Include System User With Identity, all system users are included in parsing, regardless of the System User Criteria parameter value.
Configuring JSA 7.3 versions to identity system users in events
By default, all usernames that end with a dollar sign ($) are considered as system users and are excluded from event parsing. If you want to change the way that JSA 7.3 versions maps these events, you can include usernames that end with a dollar sign ($) by using the command line.
-
Using SSH, log in to your JSA Console as the root user.
To create a new properties file or to edit an existing properties file, type the following command:
vi /opt/qradar/conf/WindowsAuthServer.properties-
If you want usernames that end with a dollar sign ($) to always be considered as system users, choose one of the following options:
Delete the following lines:
systemUserEndsWithDollarSign=falsesystemUserMatchesComputerName=trueOr
systemUserEndsWithDollarSign=falsesystemUserMatchesComputerName=falseReplace the existing lines from Step 3a with the following lines:
systemUserEndsWithDollarSign=truesystemUserMatchesComputerName=false
If you want usernames that end with a dollar sign ($) to be considered as system users only when they match the computer name, add the following lines in the text file:
systemUserEndsWithDollarSign=falsesystemUserMatchesComputerName=trueTip:A username is considered to match the computer name when the username (excluding the dollar sign) is equal to the computer name or, if the computer name is a fully-qualified domain name, the host component of the computer name. Letter case is ignored. For example, if the username is HOST$ and the computer name is host or host.example.com, then the username is considered to match the computer name.
If you want usernames that end with a dollar sign ($) to never be considered as system users, add the following lines to the text file:
systemUserEndsWithDollarSign=falsesystemUserMatchesComputerName=false-
Save your changes and then exit the terminal.
-
Restart the event collection service. For more information, see Restarting the event collection service.
Microsoft Windows Security Event Log Sample event message
Use these sample event messages to verify a successful integration with JSA.
Due to formatting issues, paste the message format into a text editor and then remove any carriage return or line feed characters.
Microsoft Windows Security Event Log sample messages when you use WinCollect
The following sample has an event ID of 4624 that shows a successful login for the <account_name> user that has a source IP address of 10.0.0.1 and a destination IP of 10.0.0.2.
<13>May 08 10:45:44 microsoft.windows.test AgentDevice=WindowsLog
AgentLogFile=Security PluginVersion=7.2.9.108 Source=Microsoft-Windows-Security-Auditing
Computer=microsoft.windows.test OriginatingComputer=10.0.0.2 User= Domain=
EventID=4624 EventIDCode=4624 EventType=8 EventCategory=12544 RecordNumber=649155826
TimeGenerated=1588945541 TimeWritten=1588945541 Level=Log Always Keywords=Audit Success
Task=SE_ADT_LOGON_LOGON Opcode=Info Message=An account was successfully logged on.
Subject: Security ID: NT AUTHORITY\SYSTEM Account Name: account_name$ Account Domain:
account_domain Logon ID: 0x3E7 Logon Information: Logon Type: 10 Restricted Admin
Mode: No Virtual Account: No Elevated Token: Yes Impersonation Level: Impersonation
New Logon: Security ID: account_domain\account_name Account Name: account_name Account
Domain: domain_name Logon ID: 0x9A4D3C17 Linked Logon ID: 0x9A4D3CD6 Network Account
Name: - Network Account Domain: - Logon GUID: {00000000-0000-0000-0000-000000000000}
Process Information: Process ID: 0x3e4 Process Name: C:\Windows\System32\svchost.exe
Network Information: Workstation Name: workstation_name Source Network Address: 10.0.0.1
Source Port: 0 Detailed Authentication Information: Logon Process: User32 Authentication
Package: Negotiate Transited Services: - Package Name (NTLM only): - Key Length: 0 This
event is generated when a logon session is created. It is generated on the computer that was
accessed. The subject fields indicate the account on the local system which requested the
logon. This is most commonly a service such as the Server service, or a local process such as
Winlogon.exe or Services.exe. The logon type field indicates the kind of logon that occurred.
The most common types are 2 (interactive) and 3 (network). The New Logon fields indicate
the account for whom the new logon was created, i.e. the account that was logged on. The
network fields indicate where a remote logon request originated. Workstation name is not always
available and may be left blank in some cases. The impersonation level field indicates the
extent to which a process in the logon session can impersonate. The authentication information
fields provide detailed information about this specific logon request. - Logon GUID is a
unique identifier that can be used to correlate this event with a KDC event. - Transited
services indicate which intermediate services have participated in this logon request. -
Package name indicates which sub-protocol was used among the NTLM protocols. - Key length
indicates the length of the generated session key. This will be 0 if no session key was
requested.The following sample has an event ID of 4624 that shows a successful login for the <target_user_name> user that has a source IP address of 10.0.0.1.
<13>May 08 14:54:03 microsoft.windows.test AgentDevice=NetApp AgentLogFile=Security PluginVersion=7.2.9.108 Source=NetApp-Security-Auditing Computer=00000000-0000-000000005-000000000000/11111111-1111-1111-1111-111111111111 OriginatingComputer=00000000-0000-0000-0000-000000000000/11111111-1111-1111-1111-111111111111 User= Domain= EventID=4624 EventIDCode=4624 EventType=8 EventCategory=0 RecordNumber=6706 TimeGenerated=1588960308 TimeWritten=1588960308 Level=LogAlways Keywords=AuditSuccess Task=None Opcode=Info Message=IpAddress=10.0.0.1 IpPort=49155 TargetUserSID=S-0-0-00-00000000-0000000000-0000000000-0000 TargetUserName=target_user_name TargetUserIsLocal=false TargetDomainName=target_domain_name AuthenticationPackageName=NTLM_V2 LogonType=3 ObjectType=(null) HandleID=(null) ObjectName=(null) AccessList=(null) AccessMask=(null) DesiredAccess=(null) Attributes=(null)
Microsoft Windows Security Event Log sample message when you use Syslog to collect logs in Snare format
The following sample has an event ID of 4724 that shows that an attempt was made to reset an account's password, and that the attempt was made by the account name Administrator.
The logs that you send to JSA must be tab-delimited. If you cut and paste the code from this sample, make sure that you press the tab key where indicated by the <tab> variables, then remove the variables.
<133>Aug 15 23:12:08 microsoft.windows.test MSWinEventLog<tab>1<tab>Security<tab>839<tab>Wed Aug 15 23:12:08 2012<tab>4724<tab>Microsoft-Windows-Security-Auditing<tab>user<tab>N/ A<tab>Success Audit<tab>w2k8<tab>User Account Management<tab>An attempt was made to reset an account's password. Subject: Security ID: subject_security_id Account Name: Administrator Account Domain: DOMAIN Logon ID: 0x5cbdf Target Account: Security ID: target_security_id Account Name: target_account_name Account Domain: DOMAIN 355
Microsoft Windows Security Event Log sample message when you use Syslog to collect logs in LEEF format
The following sample has an event ID of 8194 that shows that the event generated a Volume Shadow Copy Service error that was initiated by the <user_name> user.
<131>Apr 04 10:03:18 microsoft.windows.test LEEF:1.0|Microsoft|Windows|2k8r2|8194|
devTime=2019-04-04T10:03:18GMT+02:00 devTimeFormat=yyyy-MM-dd'T'HH:mm:ssz cat=Error
sev=2 resource=microsoft.windows.test usrName=domain_name\user_name application=Group
Policy Registry message=domain_name\user_name: Application Group Policy Registry: [Error]
The client-side extension could not apply computer policy settings for '00 - C - Domain -
Baseline (Enforced) {00000000-0000-0000-0000-000000000000}' because it failed with error code
'0x80070002 The system cannot find the file specified.' See trace file for more details.
(EventID 8194)Microsoft Windows Security Event Log sample message when you use Syslog to collect logs in CEF format
The following sample has an event ID of 7036 Service Stopped that shows that a service entered the stopped state.
CEF:0|Microsoft|Microsoft Windows||Service Control Manager:7036|Service entered the stopped state|Low| eventId=132 externalId=7036 categorySignificance=/Normal categoryBehavior=/Execute/Response categoryDeviceGroup=/Operating System catdt=Operating System categoryOutcome=/Success categoryObject=/Host/Application/Service art=1358378879917 cat=System deviceSeverity=Information act=stopped rt=1358379018000 destinationServiceName=Portable Device Enumerator Service cs2=0 cs3=Service Control Manager cs2Label=EventlogCategory cs3Label=EventSource cs4Label=Reason or Error Code ahost=192.168.0.31 agt=192.168.0.31 agentZoneURI=/All Zones/example System/Private Address Space Zones/RFC1918: 192.168.0.0-192.168.255.255 av=5.2.5.6395.0 atz=Country/City_Name aid=00000000000000000000000\ \=\\= at=windowsfg dvchost=host.domain.test dtz=Country/City_Name _cefVer=0.1 ad.Key[0]=Portable Device Enumerator Service ad.Key[1]=stopped ad.User= ad.ComputerName=host.domain.test ad.DetectTime=2013-1-16 15:30:18 ad.EventS
Microsoft Windows Security Event Log sample message when you use Syslog to collect logs by using Winlogbeat
The following sample has an event ID of System that shows that NtpClient was unable to set a manual peer to use as a time source.
{"@timestamp":"2017-02-13T01:54:07.745Z","beat":
{"hostname":"microsoft.windows.test","name":"microsoft.windows.test","version":"5.6.3"},"compute
r_name":"microsoft.windows.test","event_data":
{"DomainPeer":"time.windows.test,0x9","ErrorMessage":"No such host is known.
(0x80072AF9)","RetryMinutes":"15"},"event_id":134,"level":"Warning","log_name":"System","message
":"NtpClient was unable to set a manual peer to use as a time source because of DNS resolution
error on 'time.windows.test,0x9'. NtpClient will try again in 15 minutes and double the
reattempt interval thereafter. The error was: No such host is known.
(0x80072AF9)","opcode":"Info","process_id":996,"provider_guid":"{00000000-0000-0000-0000-0000000
00000}","record_number":"40292","source_name":"Microsoft-Windows-Time-
Service","thread_id":3312,"type":"wineventlog","user":{"domain":"NT
AUTHORITY","identifier":"user_identifier","name":"LOCAL SERVICE","type":"Well Known Group"}}Microsoft Windows Security Event Log sample message when you use Syslog to collect logs by using Azure Event Hubs
{"time":"2019-05-07T17:53:30.0648172Z","category":"WindowsEventLogsTable","level":"Informational
","properties":
{"DeploymentId":"00000000-0000-0000-0000-000000000000","Role":"IaaS","RoleInstance":"_role_insta
nce","ProviderGuid":"{00000000-0000-0000-0000-000000000000}","ProviderName":"Microsoft-Windows-
Security-
Auditing","EventId":5061,"Level":0,"Pid":700,"Tid":1176,"Opcode":0,"Task":12290,"Channel":"Secur
ity","Description":"Cryptographic operation.\r\n\r\nSubject:\r\n\tSecurity
ID:\t\tsecurity_id\r\n\tAccount Name:\t\taccount_name\r\n\tAccount
Domain:\t\tWORKGROUP\r\n\tLogon ID:\t\t0x3E7\r\n\r\nCryptographic Parameters:\r\n\tProvider
Name:\tMicrosoft Software Key Storage Provider\r\n\tAlgorithm Name:\tRSA\r\n\tKey
Name:\t{11111111-1111-1111-1111-111111111111}\r\n\tKey Type:\tMachine key.\r\n\r\nCryptographic
Operation:\r\n\tOperation:\tOpen Key.\r\n\tReturn Code:\t0x0","RawXml":"<Event xmlns='http://
schemas.microsoft.com/win/2004/08/events/event'><System><Provider Name='Microsoft-Windows-
Security-Auditing' Guid='{22222222-2222-2222-2222-222222222222}'/><EventID>5061</
EventID><Version>0</Version><Level>0</Level><Task>12290</Task><Opcode>0</
Opcode><Keywords>0x8020000000000000</Keywords><TimeCreated
SystemTime='2019-05-07T17:53:30.064817200Z'/><EventRecordID>291478</EventRecordID><Correlation
ActivityID='{33333333-3333-3333-3333-333333333333}'/><Execution ProcessID='700' ThreadID='1176'/
><Channel>Security</Channel><Computer>computer_name</Computer><Security/></
System><EventData><Data Name='SubjectUserSid'>subject_user_sid</Data><Data
Name='SubjectUserName'>subject_user_name</Data><Data Name='SubjectDomainName'>WORKGROUP</
Data><Data Name='SubjectLogonId'>0x3e7</Data><Data Name='ProviderName'>Microsoft Software Key
Storage Provider</Data><Data Name='AlgorithmName'>RSA</Data><Data
Name='KeyName'>{44444444-4444-4444-4444-444444444444}</Data><Data Name='KeyType'>%%2499</
Data><Data Name='Operation'>%%2480</Data><Data Name='ReturnCode'>0x0</Data></EventData></
Event>"}}