Sysmon (short for system monitor) has been part of the Sysinternals suite for several years. It comprises kernel-mode driver and a Windows service that monitors system events and writes those to Windows event logs. The fact that it is a kernel mode driver gives it a significant advantage over many other monitoring agents. As an example, some monitoring agents claim to be able to capture process creation, however their approach may be to simply poll the process tree every second or so. Any process launched outside of the polling window will be missed. A kernel mode driver is “always on” and can therefore be programmed to capture every single process creation event.
As sysmon is a kernel-mode driver, it also has the ability to provide much greater visibility into the internal activity of the operating system. Increasingly, malicious activity is occurring in memory, leaving little or no trace on the disk. Memory forensics is the most robust method of detecting in-memory attacks but it is challenging to do this at scale and is expensive in terms of resources to perform. Sysmon is no alternative to memory forensics, but it is an excellent tool for identifying systems that may be worthy of such an investigation.
Sysmon uses a configuration file to dictate what events can be captured. A fairly recent development is the extension of the configuration file capabilities; this gives a high degree of flexibility in relation to the type of events that can be captured and the conditions that will trigger the logging of an event.
Installation is simple; to deploy to a single system, launch a terminal with administrator privileges and change to the folder containing sysmon and the configuration file. Issue the command sysmon64.exe –accepteula –i config_file_name.xml
You should see some messages confirming that the installation completed successfully, as shown below:
The configuration file should be tuned to your environment, making sure that known good events are excluded from logging (unless you want to use Sysmon for comprehensive process auditing). Before deploying sysmon you should really understand what you want to use it for, as it has a number of use cases:
- Comprehensive process auditing – every single process, including command line activity can be logged.
- Malicious activity logging – interesting events that are indicative of malicious activity can be logged. This would include an executable in a users profile writing to a system process space.
- Desired state assurance – capture instances where your desired state is deviated from e.g. an expected HIPS process is absent or an unauthorised process is run.
This decision may be guided by your existing defensive posture. If you have a SIEM in place then this could ingest your sysmon logs. However, if you use a Messages per Second payment model, this could significantly increase your costs if you have configured sysmon for comprehensive process auditing. It may be that you have SCCM deployed and you could configure this for process auditing and configure sysmon to capture malicious activity. Another consideration is the ability to use Windows Event Forwarding to forward potential malicious activity logs to a collector whilst retaining process auditing logs on the original host.
Once you have decided on the objective of your sysmon deployment, you can configure the configuration file. If you want to perform comprehensive logging you will need to create a configuration file that logs the following:
- All process creation events
- All network connections
- All loaded drivers
- All image loading
If want to capture malicious events, you will be more interested in logging the following event types:
- Command line or PowerShell processes
- Suspicious network events e.g. those going to port 80/443 that aren’t initiated by a web-browser, email client, chat client etc.
- Unusual instances of process injection
- Unusual instances of a process accessing another process
In these circumstances you will need to establish what is “normal” in your environment. Process injection and process access is used legitimately by a number of non-malicious processes. You will need to discover what those are by deploying sysmon with a configuration file that captures all of those types of events, then exclude the events that occur normally in your environment (after you have confirmed that they aren’t malicious!).
Below is an extract from a configuration file that seeks to detect the lsass and cmd process spaces being accessed by another process. The configuration file is XML based and allows the logging of event types and the filtering of the event types. In our case, after configuring sysmon to include the logging of lsass and cmd ProcessAccess events we then filter out the logging of executables that legitimately access those processes.
Once you have eliminated the noise being logged by sysmon, malicious activity becomes much easier to spot. In a test we ran shellcode on a compromised system running sysmon and configured to capture events where the lsass.exe and cmd.exe process were accessed by another process, sysmon Event ID 10:
We can see that a suspiciously named source image has accessed cmd.exe. Having done our tuning, we know that this is abnormal behaviour; this log would certainly cause us to investigate the source image.
Below is another example. In this case we have captured some interesting network activity using a configuration file that tuned out all the “normal” network activity.
We can see that PowerShell.exe has initiated an outbound connection to an external IP address on port 443. This event would cause us to investigate that activity.
You will need to think about counter-measures that attackers will take to try and bypass sysmon logging. Therefore, it would be wise to monitor the system log for Event ID 1. Below is an example of a System event log recording the shutdown of the sysmon service.
Sysmon is a free utility that provides a great deal of visibility into Windows systems. The log format that it uses can be ingested by most SIEM solutions to provide real time detection of malicious events. It’s well worth taking the time to get to know and implement it in your environment.
In September, we released our XSS Payloads collection of scripts and they went down really well within the pen-testing community. There are lots of other fun things you can do to exploit cross site scripting and so we’ve recently added another couple of payloads.
The payloads described in this post can be found at https://github.com/nettitude/xss_payloads.
Finding a cross site scripting vulnerability isn’t always as simple as having <script>alert(1)</script> returned back to you. Sometimes, tools like Burp Collaborator or Sleepy Puppy can identify XSS in areas which you won’t even have access to. I still recall being blown away by Burp Collaborator identifying that the web service I was injecting into was having its data reflected in an entirely inaccessible Intranet, allowing browser code execution within the client’s own internal network. The payload that Burp had generated to find this was suitably ninja-like:
But what next? How do you go from a simple request generated by a Burp Collaborator event into access to the client’s internal Intranet? Step one is to understand what you’re looking at, and that’s where recon.php comes in. If executed on a remote page, recon.php will gather as much information as it can about where it was executed:
- Non-HttpOnly cookies
- The current URL
- The HTML of the current page
- The user agent string
- User’s IP
and send it back to itself where it can be logged to either a file or a database.
You can then plan, based on what comes back, what your next attack might be. In many cases the contents of this response might contain enough information to immediately launch an exploit.
Another potentially valuable attack, especially in the context of a phishing campaign, is to hijack an existing form so that any information entered into it is captured, sent back to the attacker and then forwarded back on to the original site without the user noticing. This would work really well in areas such as login forms – with an XSS vulnerability you could carry out a credential harvesting campaign against a site, without having to go through the hassle of cloning the original login page and hosting it on a look-a-like domain; the user would be going to the real site.
On it’s own this is powerful, but we can exploit browser functionality and make it even better. By adding in and then hiding other form fields, we can exploit browser autofill and trick the user’s browser into giving away all the personal information that it has stored.
What formjacker.php does then, is to change all of the action URLs of all forms on a page to itself, add in a load of common personal information fields such as phone number, address and credit card information and then allow the user’s browser to automatically propagate them. All this info is transmitted back to us, the attacker. The script then dynamically creates a copy of the original form and submits it back to where it was originally supposed to go, all without the user noticing.
Here is a demonstration of the attack within a test environment:
The user just sees the same form they normally would:
They can even view source. Note that we have our script included in the page header.
However, if we look at what HTML the browser has in memory…
We can see that we’ve just added in a load of contact information fields. Note that they all have an absolute position of -500px which positions them outside of the browser view, effectively rendering them invisible. Despite this, Chrome will still autofill the fields with any information it has, so when a user hits submit…
All of this information is received by the script, which then writes it all to file or database.
The script then responds by creating an auto-submitting form to send the user back to where they were expecting the form to submit to, hopefully leaving them none the wiser that we just stole their data.