Collecting & analysing Windows event logs with Winlogbeat & ELK

in a previous video we saw how some malicious activity could be identified just by monitoring network traffic but network traffic alone doesn't provide much insight into what's occurring on individual machines windows collects a bunch of useful information within its event logs which can help but it can be hard picking out the relevant entries amongst the noise and the default event viewer is not particularly friendly or powerful but thankfully there is a better way hey there i'm andy and in this video we'll be looking at how to centrally collect and analyze windows event logs in an elk stack using wind lobbies windows logs are created in several different sections within the event viewer some of the most significant from a security perspective are unsurprisingly within the system and security sections but there's also a lot of use within the applications and services logs for example powershell logs or logs relating to core internal services the event viewer provides a basic means of sorting events and filtering but the interface limits these actions to just a subset of fields for example take event id 4624 a user logon selecting one of these events provides a wealth of additional information such as which user logged on to which machine and the logon type which indicates whether the logon was to a local machine via a network or via rdp and so on what if we wanted to filter this list to see whether there's any occurrence of the administrator user logging onto this machine via rdp from the filter interface we can specify the event id we're interested in and there's a user field but this filters based on this user field not the actual account name and there's nowhere at all to specify the logon type and if this all weren't bad enough remember that there's key events occurring across different logs but there's no easy way to pivot between them and of course these are just the logs from a single local machine in many cases we might want to compare events from different machines hopefully by now it's fairly obvious why we might want to collect logs into one central place which has a far better search and analysis capability an elk stack provides one such method of doing this and the security onion sensor from the previous video includes exactly that out of the box in that video i vastly oversimplified the architecture suggesting that elk is a single component it's actually three a combination of elasticsearch a database logstash a login gesture and kibana a visualization tool winlogbeat is the glue that picks up the windows event logs and pushes them into logstash preparing our out-of-the-box security onion standalone instance from the previous video is pretty simple we just need to reconfigure the firewall using the sol program to allow clients on the local network to communicate with the logs service on port 5044 each client requires the winlogb agent to be installed a link to the correct version is provided from the download section of the security onion web interface this msi installs the windlog beaker service along with the sample config file which needs modifying to route data into logstash rather than directly into elasticsearch which is the default so we need to comment out the elasticsearch output section and enable the logstash output and configure it to send logs to the ip address of our sensor note also that this file contains a section to specify which logs and event ids should be forwarded for now we'll keep the defaults of applications system and security logs and a selection of powershell related logs with the updates made the config file can be saved with the correct name and the service started via the services ui we can verify logs are flowing by opening the kibana interface and navigating to the host dashboard here we can see how many log events have been transferred so far manually installing the winlogb agent on every device is rather inefficient but thankfully the steps we've just been through can be automated via group policy but before we get to that let's head on over to the discover section and have another go at trying to find out if there's any cases where someone has rdp'ed into this machine as the administrator account we can start with a search for all items where the event id is 4624 which returns all of the successful logons each of the entries here lists their properties as a big wall of text which isn't particularly easy to read the arrow next to the side expands the events to list them individually this is a great way to explore the different fields available within each type of event to work out which ones are of potential interest to drill down into or to filter off of items of interest can be added to the column view via the table icon on each row here i'm adding the device hostname username logon type and source ip address once the event details are contracted these properties are easily visible for all entries to find entries associated with the administrator user we could edit the query to add this as an additional search condition or as i'm doing here apply a filter with the filter set we can see a handful of events with one in particular being logon type number 10. this indicates a successful rdp logon to the domain controller from ip address 192.168.1.11 properties like logon type can be a bit cryptic how do i know that 10 means an rdp logon well google is your friend here and in particular the ultimatewindowsecurity.com site has an encyclopedia of event codes and their details which is an invaluable resource until you've managed to commit some of the most common items to memory to finish up let's run through how we can deploy winlogbeat at scale via group policy the two key files needed are the install msi and the config file so let's copy them to the netlogon folder so all client devices can access them next up a new policy is required i'm creating one here for all of the workstations in this lab to install the agent software we can configure a software installation from the computer policies section and specify the msi file from the netlogon share to apply our modified config file a file copy can be created from the computer preferences windows settings the action here must be to replace and we just need to specify the source file from the net logon share and the destination folder within the local machine's program data directory to ensure the service is then started a service policy can be defined from the computer preferences control panel section we define this policy to be applied to the win log beat service and specify it should automatically run on startup and to specify specific action to start the service immediately here i'm also configuring the service to restart every five minutes if it fails for any reason with the policy now defined we just need to wait for clients to pull the latest changes and they'll be automatically applied after a few minutes a refresh of the kibana interface shows we're now receiving events from all three of the windows workstations in this lab there's a couple of final points i should highlight with this configuration before we finish up the video the first is around the selection of events we kept the defaults of application system security and some powershell logs this is a good start but may not provide detection for all of the threat scenarios that you might be interested in so you may want to add more to the win log b configuration now whilst feeding in more events is great for better visibility bear in mind the additional disk capacity required to store them and the additional cpu power required to process the events as they're fed in this might not seem very significant for a small network like my test lab here but it can add up quickly to a significant impact in a larger environment finally the default config file also does not encrypt the connection between clients and win log base but i'll leave a link in the video description to the documentation which describes how to set this up we'll be continuing to build upon this detection platform in future videos so do get subscribed if you don't want to miss it and let me know in the comments which tools and capabilities you'd add but that's all for this video if you found it useful please do give it a like and i'll see you next time [Music]

Channel: Attack Detect Defend

Views: 11,022

Keywords:

Id: 39iVugb9Y0c

Length: 9min 49sec (589 seconds)

Published: Tue Aug 10 2021