Sysmon |TOP|
Eufemia Graybill
As a defender I am continuously testing, tuning and re-testing a plethora of detection ideas across many complementary detection frameworks. However, a skilled DFIR practitioner values the confidence gained from cross-validating one tool's results with those produced by similar tools. Over the past nine months I have spent significant time researching new obfuscation and evasion techniques, and a good portion of this time I have spent validating the effects of these techniques on numerous detection artifacts and tool sets. This blog post highlights a bug I found in Sysmon's event logging that contaminates process command line argument logging and adversely affects at least two different tools used for viewing Windows event logs.
First of all, I have been a fan of using Sysmon in my personal testing lab setup since its original release in 2014. Sysmon (System Monitor) is part of Microsoft's Sysinternals Suite and was written by Mark Russinovich (@markrussinovich) -- thanks, Mark! The Sysmon driver installs as a service and logs numerous Windows events to the Microsoft-Windows-Sysmon/Operational event log. Most recently updated on January 5, 2018, v7.01 supports twenty-two different Event IDs ranging from process execution events (EID 1 & 5), network connection events (EID 3), image load events (EID 7), named pipe events (EID 17 & 18), WMI events (EID 19, 20 & 21), all the way to registry events and much more!
Over the years there have been numerous blog posts written on using Sysmon as a data collection source for endpoint visibility and threat hunting. In addition, Sysmon configurations such as @SwiftOnSecurity's sysmon-config project ( -config) have popularized the filtering capabilities that Sysmon supports for data collection tuning. Finally, Microsoft recently published the Sysinternals Sysmon Suspicious Activity Guide ( -sysmon-suspicious-activity-guide/) which serves as an even better overview than what I am attempting to convey here.
At the end of the day, an increasing number of defenders rely on Sysmon for some level of endpoint visibility and it is worth cross-comparing Sysmon as a data source with similar but officially supported (by Microsoft) data sources before one begins or continues investing detection logic applied to data logged and collected from Sysmon. In particular, it is encouraged to test both the data source and the tooling used to query, aggregate and analyze the data source in question.
I have successfully installed sysmon and verified the schemaversion matches the schemaversion in the config file (sysmonconfig-export.xml by SwiftonSecurity). I have confirmed that sysmon is running in event viewer (Application and Service Logs > Microsoft > Windows > Sysmon > Operational).
I downloaded and installed the TA-microsoft-sysmon on the search head I use.
I also copied the TA-sysmon folder to the deployment server (\Splunk\etc\deployment-apps\TA-microsoft-sysmon) and then deployed it to my UF running on my test host.
It would be more (computationally) efficient to define the desired on index on the endpoints via index = winsysmon spec in inputs.conf than it would be to transform/reroute the events on the indexers via props/transforms.conf. The indexers are going to busy enough extracting XML fields at search time for that dense sysmon data set.
Yes, the index must exist on the indexers first.
The index = attribute merely tells Splunk where to store your data. It does not create the index itself.
Put index = winsysmon in the XmlWinEventLog stanza of props.conf. Restart Splunk and data should go to the right place.
Ok thank you for the reply.
So then (following your answer) please verify that I am understanding correctly,
step one put the index on the indexers in indexes.conf and restart the indexers
step two put [index=winsysmon] in the props.conf in the Sysmon-TA prior to deploying to the UF
Based upon the new logging enhancements to the IDR platform, I am confused as to whether or not these logs are now automatically being collected. The notification to customers states that all System/Security/Application logs on Windows Endpoints are now collected. If that is the case, where can I find my sysmon logs?
Stephen and Jan, to be honest from all the documention I have read over the last few months, there was not one that told me about the back alleys I would have to take to have sysmon to show up in my SOC.
I am sure that everyone trying to use SOC will have thier own set of circumstances, so I am not blaming the documentation thats out there.
Stephen, sorry for the confusion. Of course i am installing sysmon, winlogbeat and elasticsearch on my laptop on windows 10 and 11.
I have heard it could be risky to use the public Ipv4 IP spectrum provides. So, there are certain tools you want only on a VM. I reserved this IP with spectrum and gave .214 and created an IP of .216 to use as a static IP.
Hi jan, thanks for getting back, sorry it took so long to respond. I am trying to do Stephens a, sysmon > winlogbeat > elasticsearch.
looked at output plugins (have not seen this requirement in all of what I have read) : Output plugins Logstash Reference [8.11] Elastic
but there are so many.
Maybe you have a link that explains why I need a plugin. I have not seen that as a reqiuirement to have this scenario to work?
even though there were already lots of events happened and I can list them by running Get-WinEvent -LogName 'microsoft-windows-sysmon/operational' in PowerShell. I don't see them in the System event log either
I've got a small logging server running at the moment and it's successfully recording events forwarded in from our various Windows clients. I'm using NSA cyber's WELM project from github to target events. It's all working.
I'm also deploying Sysmon to provide further diagnostic information.
I'm using a GPO to deploy Sysmon and I've checked: it is running on the clients. Events are being recorded in the client logs but nothing is appearing in the forwarded logs on the log server. If I check in subscriptions - no clients are checking in.
As far as I can tell I've configured access for NETWORK SERVICE to have access to the logs correctly (events ARE being forwarded) for everything except sysmon.
Sysmon's log is part of "Applications and Services logs" and I'm wondering if I need to configure additional access to the Sysmon log? And if so - HOW? I can't find the options in Group Policy.
Can anyone point me in the right direction?
Points are waiting!
This produces two CSV files, one file contains matches and one file contains hashes without matches. Searching the file with matches will tell us if there were any hashes on VirusTotal with a high confidence of positive anti-virus detects. If a hash is deemed suspicious, copy the hash and search the sysmon_parsed.txt file to see which process and command line are responsible for the entry. Keep in mind that not all suspicious hashes will have matches on VirusTotal.
After the IP Addresses have been resolved and the WhoIs information has been collected, it is easy to view and sort the results. After completing this process once or twice and collecting a nice baseline of results, it should be easy to pick out information that seems out of place. For instance, it is easy to sort by Country to see if any unexpected connections have been made. If an IP Address warrants further follow-up, search the sysmon_parsed.txt file to see which process is making the connection.
Looking through these XML parsed entries isn't really Linux admin friendly. To overcome this Sysmon bundles with a tool called 'sysmonLogView' to parse these entries more user friendly. Let's dive into that later.
We now have a user friendly view on the Events that occurred. We can also use sysmonLogView for further filtering like eventid ( with argument ), certain time window or which fields to display. In our case we could filter out our 'touch' events with
For decades, the Run and RunOnce keys in the registry have been favorite bad-guy locations for persistence, but we know to monitor them using Windows auditing for sysmon. This is so that attackers in-the-know have moved on to WMI.
Get hints for the average sysmon report corresponding to the request time interval. To override the default hints parameters use ConfigFile api. See HConfig data type in SysmonTypes package for the list of the configuartion parameters.
df19127ead