Level-up your host-based monitoring with Sysmon

a single alert about a potential compromise isn't much use unless you can follow the trail of digital breadcrumbs backwards to identify the initial entry vector and forwards to uncover what mischief an attacker has been up to that trail can quickly run cold if you're not capturing device events in sufficient detail hi there i'm andy and in this video we'll be exploring how to level up your host-based monitoring with cismod [Music] if you've watched some of my previous videos about attacker tools tactics and procedures you'll have seen how often they rely on writing to files or registry entries and almost all attack chains include some element of launching a new process or establishing a network connection these are all key events which are hugely useful in investigating suspicious behavior and sysmon part of the 3d available sysinternal suite provides a great way of recording them a quick browse of the sysmon webpage shows the various events it captures including not only those which i just mentioned but also process terminations drivers being loaded raw disk access creation of alternate data streams usage of named pipes wmi events dns queries and file deletions to see the power of sysmon in action i've simulated an attack against the system in my test lab the only alert that this attack generated from the network ids is about a potential metasploit payload originating from 10.2.0.143 to 192 168 1.11 let's pivot off these details to see what further light systems can shed on the situation using the cabana interface we configured in a previous video let's look for all events which combine both of these two ip addresses by entering them into the search bar with an and operator between them three results are returned i'll tweet the kibana interface view here to show the source and destination ip import and also what machine and module the event is from the second event is the same surakarta alert which appeared in the alerts list earlier the other two events are from sysmon and zeke both of them reporting on the tcp connection over which the potential metasploit payload was detected this shows that although the payload was transferred from 143 to 11 the tcp connection itself was actually established from 11 2.14 the zeke event was created from passively observing network traffic so it has no further information about what process on when ws1 was responsible for it but sysmon does expanding this out we can see the process which established this suspicious connection was a strangely named exe file running from a temp folder we can learn more about this process by modifying the search query to pivot off the process id number we also need to add the hostname to the query as we're only interested in the details associated with process id 3208 on this machine not any other machine and i'll also add the event.action to the column view to give a better view of these events also note that my lab environment here only has events for a very short period of time but in a real implementation you'd also want to think about filtering within a specific time window too as process ids get reused this view shows that after the process was created two network events occurred then the process terminated the first of these was the connection we saw earlier to 10.2.0.143 on port 4444 but now we can also see that a short time later a second connection was established to 192.168.1.5 on port 22. it looks like this attacker used the compromised workstation to then move laterally and log into a linux server on the internal network at this point it'd be smart to pivot off this event and examine the logs of this linux host but so far in this series we've not quite gotten around to setting that up yet do you get subscribed though as we'll be covering linux host login very soon in the meantime let's see if cis1 can help us track down what the initial entry vector was for this attack and if the attacker caused any other mischief taking a closer look at the process creation event we can see that this strangely named exe file was launched from wscript.exe this is the windows script in host and is used to run vbscript and javascript files the specific vbscript file is named staff salary database and is stored on the e-drive perhaps an unwitting user has found an interestingly named usb stick lying around and couldn't resist the urge to check its contents we can get more information by examining this parent process in more detail sysmon provides the pit of the parent process so we just need to update our query with the relevant id the creation event associated with this process shows it was launched by explorer.exe adding further weight to the theory that this was executed by a user the other event associated with this process is the creation of the strangely named exe file earlier the final avenue we'll explore in this simulated attack is whether any further processes were launched by updating the query to show any events where the parent pid is that of wscrip.exe this produces just one result that strangely named exe file let's repeat the query for this process and we see that it also launched a command prompt shell and pivoting of that parent pid shows the list of the commands which the attacker ran in their shell who am i and ipconfig so putting this all together it looks like a user ran a vbscript they found on a usb stick which created and ran a malicious exe payload which in turn established a command control session back to the attacker the attacker launched an interactive shell to gather some details about the user and network and then use the connection to pivot onto another machine over ssh okay so by now hopefully i've managed to demonstrate just how great this one is at unpicking malicious behavior installing it is pretty simple after downloading from the microsoft website we just need to run it with the dash i option to install it as a system service which will then run on startup and specify the configuration file to use this config file is really important to ensure that the events you're interested in are captured whilst eliminating the noise of normal system activity which would otherwise generate lots of useless events and impact performance we'll explore this in more detail later in the video but for now we'll just take advantage of a starter config file developed by swift on security check out the link in the video description to grab a copy of it yourself with this one installed we can open up the event viewer and locate the sysmond event log under applications and services events are already being created for process creations registry modifications and dns lookups but as i've said before this interface is terrible for viewing and investigating them so in my lab environment demoed earlier i'd configured this server to push some of its logs to an elk stack via winlogbeat i'll leave a link in the video description to a previous video explaining the initial setup but for this video let's just tweak the config to also include the sysmon events we just need to open up the winlogbe config file located in c drive program data and add the following line to include the syslog events with the changes saved we just need to restart the winlogbeat service for it to take effect to check it's all working we can head over to our kibana instance and under the hosts dashboard filter events by the sysmond module as with our original win log beat deployment from the previous video the steps needed to install sysmon can also be automated via group policy the config file and sys1 executable just need placing in a folder under netlogon along with a batch file which takes care of the installation or updating of sysmon then a new gpo is created for all workstations in this domain with a startup job to run the install and update script every time the machine boots up the script itself just copies over a config file from the net logon share and triggers the system on reload in case it's already installed it then checks to see if sys1 is currently running and if not install it start it and trigger a restart of the winlogbeat service back in kibana a refresh of the dashboard shows events now flowing in from the three workstations in this lab i mentioned earlier how important it is for sys1 to be correctly configured to eliminate unnecessary noise just like many other log sources sysmon can produce a lot of data not only would this make it difficult to spot items that are malicious but it can also have a serious performance impact on both endpoints and login servers the swifton security configuration file we used earlier is a really great starting point however it's important to understand its design objectives and therefore limitations for example the comments under the network connection section of the config file state that it takes a very conservative approach to network login and triggers only on extremely high signal events just beneath we can see that the network connected events are configured on an explicit include basis only activity that matches one of these conditions will create a log event within this list is the c drive users prefix which is where the suspiciously named exe file was created before being launched hence we were able to observe its network events but had the vbscript created the exe in a different folder say on the usb drive itself it wouldn't have matched any of the file name rules later in the config there's some more explicit includes around the destination port number which would have triggered on the ssh connection regardless of the location of the exe and whilst there's a rule here which is intended to do the same for metasploit related communications the most recent version at the time of recording has a typo that makes it ineffective but even if that weren't the case it'd be trivial for attackers to just change the port number of their commander control server and evade detection by this particular sysmon configuration so again use this config file as a starting point but take the time to understand it and tune it to your particular environment another fantastic resource to help is olaf hatong's modular system repository where he maintains snippets of config which you can pick and choose from in order to identify specific known bad activities of particular interest to you and exclude known good activities which would otherwise generate false positives or excessive noise and that tuning process should be a continuous activity to react to evolutions in both your it environment and your threat landscape if you do this sysmon can provide an incredibly rich seam of host event data to help identify and investigate attacks that's pretty much all for this video but do get subscribed if you want to see more defensive tools and techniques in action let me know in the comments if there's any in particular you think i should take a look at next and if you found this video useful please do give it a like and a share i'll see you next time [Music] you

Channel: Attack Detect Defend

Views: 5,695

Keywords:

Id: gZpp4w3inzc

Length: 12min 5sec (725 seconds)

Published: Tue Oct 12 2021