We are going to quickly touch on something which frustrated me for a short while and it is related to the default configuration used by “WECUTIL” when setting up WEF (Windows Event Forwarding).
Previously I had always forwarded logs from my endpoints into Graylog using either nxlog/syslog or OSSEC so had never had this issue before. I noticed after setting up WEF that my logs in Graylog did not contain the full message field which it always had previously. At this point I’d like to point out that I do not need this field in all my logs however it is nice to have in some cases so I wanted to look at why.
It was due to the default setting of WECUTIL when setting up WEF. It is set to “RenderedText”. When this is set the messages for our test domain appear as below.
To enable us to get the full message we need to run the following command on the Event Log Server from an elevated Powershell Window. (Make sure to replace “name of subscription” with the name of your own subscription. You can run the command without specifying a subscription name but I don’t recommend doing this as it may create a hell of a lot of traffic and crash your network. Do a test first if you want to enable this, create a new subscription for a single eventID then apply this change and monitor. Only if you are happy should you roll this out to all machines.
wecutil ss "name of subscription" /cf:Events
If this causes issues you can roll back using the command below;
wecutil ss "name of subscription" /cf:RenderedText
Let’s assume all is OK after it is enabled and take a look at the differences in the forwarded messages in Graylog.
As I said previously, this is useful in some cases depending on your setup, and if you are sending them to a SIEM or not. I just thought I’d show that this can be configured natively in Windows if required. It was something I did not know about so it might help someone else.
This is the third tutorial in the “Free SIEM” series.
Today the aim is to set up log forwarding to a central log Server from all our end points with Group Policy, and as an added bonus we are going to forward all Sysmon logs as well.
For the topology we have a Domain Controller (DC), and separate Event Log collector server (EL), and other Windows Desktops on the domain (WD).
First we open Group Policy Management Console on our DC, to create a new GPO for our forwarding rules. For the purpose of this tutorial our test domain is named “glitchcorp.co.uk”, wherever you see this you should replace with your own FQDN.
Our new Policy is named “Event Forwarding”
Go to “Computer Configuration/Policies/Administrative Templates/Windows Components/Event Forwarding” to create our Target Subscription – basically the log server which will be collecting all the forwarded logs (EL). Right-click the highlighted option.
Enable the setting and then copy the highlighted text and add your server details and set the final option (Refresh=) to 60 as shown.
Save the configuration. Now we set permissions for the Security log to ensure it can be read. Go to; “Computer Configuration/Policies/Administrative Templates/Windows Components/Event Log Service/Security” Right-click and “edit”
Enable the setting, but we need to permission string for the “Log Access” box. For this we need to open Powershell.
We use “wevtutil.exe” to get the existing permissions and add the new account to the end. Run the command below then copy the string that is returned. Paste this into your “Log Access” box but at the end add either (A;;0x1;;;NS) or (A;;0x1;;;S-1-5-20). This will give the “NETWORK SERVICE” read access to the logs. (NOTE: Due to the way Sysmon works this will not grant access to Sysmon logs. We will set this in the Registry using a different method)
Save your settings. Next we go to “Computer Configuration/Policies/Windows Settings//Security Settings/Restricted Groups” Right-click and Add Group as shown.
Then add the members as shown. (You only need one entry for the NETWORK SERVICE but I had some issues so added both ways here then saved. If it identifies both without issues, then keep “NT AUTHORITY\NETWORK SERVICE”, and remove the other). Save your settings.
Now we make the Registry change for Sysmon log permissions.
Go to; “Computer Configuration/Preferences/Windows Settings\Registry” and Right-click to add new Registry Item.
Complete as shown. The full path is shown below, and the Value data is the same as we used earlier.
This is the “key path”
This is a reminder of the Powershell query
Paste this into your “Value Data” box but at the end add either (A;;0x1;;;NS) or (A;;0x1;;;S-1-5-20) as before. This will give the “NETWORK SERVICE” read access to the logs. Save your settings.
NOTE: Don’t run the below command. This is just to show basically what the Registry entry is doing, and give you some understanding. You could run this command if you were forwarding logs from a single machine but in a large environment you should use Group Policy to prevent using lot’s of scripts, or running the same thing over and over on each individual machine.
OK so we have now setup the Log forwarding location, and the permissions required, now we need to ensure the required services are running on the source computers on the Domain so they can forward the logs to our collecting server.
Now we need to configure the Firewalls to listen, and allow them to “push” the Event Logs to the EL server.
Go to; “Computer Configuration/Policies/Administrative Templates/Windows Components/Windows Remote Management/WinRM Service” and right-click the highlighted options.
Configure as shown.
Save your settings. Now we go to “Computer Configuration/Policies/Windows Settings/Security Settings/Windows Firewall with Advanced Security”
Right-click “Inbound Rules” New Rule
Complete each box as shown
That’s the GP work completed so let’s open powershell on the DC and update the domain policy. You can also run this command on any endpoints you want to ensure are up to date with these settings reading for testing.
If you want to test that an endpoint is receiving the new policy you can use the command below. You can see under “Applied Group Policy Objects” our “Event Forwarding” policy is there.
NOTE: Each of the endpoints you will be sending logs from may need to have the following command run from an elevated Powershell window “WinRM quickconfig”.
It all depends on what OS you are running, but if it is already running, this command will not do any harm. If running Win 10/Server 2012 R2 it should already be running.
We head over to our EL server now and start to complete the set up on the collector. Run the below from an elevated powershell window.
Then open Event Viewer
Let’s create our first subscription. Right-click and create a new Subscription.
That’s the Sysmon Subscription sorted, now we need one for the other Windows logs.
Right-click and repeat with different settings this time as shown.
Enable both Subscriptions so they have the green tick.
You can right-click each one and check “Runtime status” this will show a list of connected machines.
Now go to “Forwarded Events” and watch all your logs come through. Make sure you are seeing entries for “Sysmon”, “Application”, “Security”, “Setup” and “System”. (Although in my screen shot all you can see is Sysmon lol!)
Congratulations! Yes it’s a bit of a slog but it is worth it. Make sure you come back for part 4.
Welcome back, and this is a quick post on something you should 100% be doing with everything you download. You should be verifying the file hash.
Let’s cover the basics first.
A file hash is basically a file which is put through an algorithm to produce a string of characters. There are many different algorithms MD5, SHA1 and SHA256 to name a few.
In our example here we are going to download the new kali Linux Virtualbox ova file shown below. (note the hash is displayed along side, and the heading tells us which hash algorithm was used)
First we download the file and copy the hash into a text file for later. Make sure you check you have copied the whole hash, and that it is the correct hash for the file you are downloading.
Now we have our file and hash text file as below.
Now while in this folder, and without highlighting the 2 files hold SHIFT and right click on the mouse. This will bring up a menu with “open powershell window here” or “open cmd window here” if you are still on Windows 7. Select whichever option you have and the windows should open.
Next we need to confirm file names and location by simply running “dir” as shown
Then from the same Window we run our certutil command which hashes our ova file.
Let’s quickly break down the command.
This is the tool we are using and the command instruction
This is the file we wish to hash
This is the hashing algorithm we want it to use.
Obviously if you don’t use the same algorithm the hashes wont match and you wont get an accurate result.
The idea is that you run the same algorithm and you should get the same result. If you don’t it means that the file has been tampered with or changed and you should not use it.
Copy the hash created in our window above and paste it into our hash file we created earlier so we can compare the two.
Excellent! A perfect match. We can now go ahead and use our file.
If a download has a hash file to check the integrity, please use it!
Was just about to finish for the day when I got this working so wanted to post before I forgot lol!
We have covered how to enable Windows Firewall logging, and how to enable and install Nxlog to allow Event Logs to be forwarded into Graylog, however up to this point I hadn’t figured out how to forward Windows log files into Graylog.
It always ends up being ridiculously simple, but hey, sometimes we have to learn the hard way!
If you haven’t setup Nxlog, or enabled Windows Firewall logging then go to the relevant blogs here and here first. as we will be assuming you already have Nxlog installed and forwarding to our Graylog server.
We just have to make a simple addition to the “nxlog.conf” file located by default at “C:\Program Files (x86)\nxlog\conf”
In the image below you will see the original “<input in>” field, and below that you can see the new “Input FileWatch” field.
Complete this as shown (unless of course you have changed the default location of your filewall log file. Mine is named “FSfirewall.log” but yours may be named differently. Browse to that location and check the name of your file before trying to configure this.
Also as you can see above, you need to add the “FileWatch” directive into the Route section of the config file. This will forward the logs through our “output” directive, which points to our Graylog logging server.
That’s it. Go to “services.msc” from powershell or cmd window and restart the nxlog service.
Now head over to Graylog and you should start seeing your Windows Firewall logs. Don’t forget if this is too noisy then you can reduce the logging conditions from within Windows Firewall Console.
Believe it or not but the Windows Host firewall does not log by default.
Some of you may not even have it enabled, but you really should. Security in depth right? If anyone believes differently please hit me up on Twitter, always happy to debate, and be educated if better practice exists.
“How do you enable firewall logging then?” I hear you shout! Well it’s actually very easy.
Let’s jump straight in. Open Windows Firewall With Advanced Security, then select “Properties” from the right-hand side of the page.
You can see from the top tab that “Domain Profile” is the active tab. If you are not sure which profile you are using you can enable for all profiles. We are using Domain so we select “Specify logging settings for troubleshooting”
Enable both options as shown below, and note the default location for the log file. Simply copy the path so you can create a shortcut or create a new folder somewhere else which is easier to find.
Click “OK” to save and that’s it.
We will look at how we use this Firewall Log in future blogs.
Recently we have been looking at a lot of Blue Team tools to help increase both the visibility of our network, and our ability to audit events.
I recently found a great Sysmon config by @SwiftOnSecurity and decided that is was time to give it a go.
The GitHub page for the config file is here and you can download Sysmon from here: so once you have downloaded both and have extracted them to the machine you are going to use, we can get started.
For this test machine I have created a folder in the root of C:\
And this this contains to contents of the extracted zip, and the config file we downloaded separately from GitHub.
The next step is to open a Powershell window with administrator privileges and install Sysmon.
First we need to move to the correct directory, then we can list the switches/options which are available. In my case the commands are as follows (If you have named your folder differently or placed it in a different location then you will need to specify the path and name you have used)
Then your window should look as below
Reading through these options helps to give us a better understanding of what we are doing.
In the case I am installing on a 64 bit machine and I wish to use the config XML file we downloaded from GitHub. From looking through the options we can see that our command to install with this file should be:
By default the logs are stored with the other Windows Event Logs here “C:\Windows\System32\winevt\Logs” Shown below
Lets set up a custom View in Event Viewer to make them easy to find. First open “Event Viewer” and select “Create Custom View”
Complete the top half of the Windows as shown, selecting only the Sysmon option in the dropdown:
Then complete the bottom half of the window as shown, selecting all keywords from the 2nd dropdown.
The completed window should look like this:
Then we give a name a save it.
That’s it. Now we can easily check our sysmon alerts with our custom template. As shown below.
Sysmon is one of a whole suite of applications from the Sysinternals tool set created by Mark Rissinovich and in the future we will be looking into a few more of these, along with “SysmonView”, and “SysmonShell” by nshalabi which are available here:
In previous posts we have covered using rsyslog to forward logs from Linux servers into Graylog, and also how to use Trend Micro’s OSSEC to forward alert logs to Graylog from both Linux and Windows, but here we will show you how to forward Windows logs into Graylog.
We won’t be covering the use of IPSEC in this tutorial, but we will cover that in the future. If you haven’t installed Graylog yet then see the guide here:
First you’ll need to download Nxlog community edition from here:
Nxlog will facilitate the sending of your Windows logs to a logging server, which in this case is Graylog.
Once you have downloaded Nxlog it’s a one click install.
Accept the license agreement and install.
Once installed check the location of the root folder as described in the README file
If when you come to start Nxlog the service doesn’t start then this is the first thing to check.
Now we have to modify the config file located as in the README file above, named nxlog.conf.
In our test environment our Graylog server is on IP 10.1.1.57 however you will need to put the IP address of your Graylog Server instead. All the other settings can be left the same. GELF is simply the format we are telling Nxlog to use when sending the data to Graylog.
That’s it for configuring Nxlog, next is to allow Nxlog through the Windows firewall.
I hope you are using host-based firewall (security in layers right?) If you don’t know how to add a rule to Windows Firewall we will run through it very quickly here.
Open “Windows Firewall with Advanced Security” and right click “Outbound Rules” and select “New Rule”
Then “UDP”, “Specific remote ports” and type in “12201” (This is also the port specified in the Nxlog config file earlier) (CORRECTION: Image shows 11201 but this is incorrect. Should show 12201)
Allow the connection (We will cover the IPSEC connection at a later date)
Select the network Profile. (The profile your network is using. If you’re not sure then Windows Firewall will say which Firewall profile is active and that relates to your network profile. If Domain Firewall profile is active, then your network profile is domain).
Then give it a name and finish the Wizard. We still need to right click our new rule from the list and adjust a few settings.
The settings below tightens the port control a little more by us explicitly specifying the local port.
This locks things down a little further as we are specifying our Graylog Server by IP.
That’s it for Windows, go to “Services” , and restart Windows Firewall and then start the nxlog service.
Now we head over to Graylog to add our new input and accept the messages.
Before we do we need to open the port on our Graylog Server.
If you have been following the previous tutorials Graylog is installed on Ubuntu Server and is using ufw. The commands to open the port in this configuration is as follows. (Don’t forget that if you have chosen a different port you will need to specify that port number instead)
sudo ufw allow 12201/udp
Then check the status
sudo ufw status
Then login to Graylog’s web interface and go to “Inputs” as shown below
Select “GELF UDP” from the dropdown and then “Launch new Input”
Select the correct node (If you only have one server then you will only have one to choose from), and complete as below except for the IP address which will be the IP of your Graylog Server.
Save then start the new input. If you receive no errors head over to the Nxlog Log file (on your Windows machine) and check for errors. (Check the README file mentioned earlier for the location).
There you have it. All done.
At this point if you have not received any messages into Graylog yet then go over to your Windows Server and restart the nxlog service. This should create a message. If not then you have either setup something wrong so retrace your steps and check through this tutorial, or if you are not receiving any errors in Graylog then it’s likely that issue is with Windows firewall. Check the nxlog file for clues. Fixing issues is where you really start to learn so don’t give up if you have issues!
For a while I’ve been testing different Web Application Firewall Solutions (WAFs) and I stumbled across WebKnight. The latest version is a paid for product but you can download the previous versions and use them for free.
WebKnight has many customisable features allowing IP blocking, URL scanning and logging. It’s compatable with OWA, WebDav, Cold Fusion, and also helps protect from SQLi, XSS, and CSRF. It’s quick and easy to setup, and after using it for a while you should find it easy to customise so it gives you what you want.
You must have ISAPI filters enabled on the Web Server.
To install and start using it go to the Aqtronix website and download the latest free version which is currently 4.5.5.
Accept the terms and conditions, then select the complete version to install.
Next launch the configuration tool, as we need to create a log folder so WebKnight can create log files.
Create a folder somewhere then remember the path and folder name for the next steps.
Find the logging section and ensure the “Enabled” box is ticked, then in the next box below enter the name of the folder then the path in the following box.
Save and close the configuration tool.
Then test your site to make sure you can still access it.
You can test by adding <script>alert(1)</script> to the end of your websites’ address then reload the page to see if you get the block page (The default WebKnight page can also be replaced by your own custom page).
This will also show in your log file.
There are countless options to play around with and it would take forever to go through them all. Configuring these options is also a good way to learn about website defence. Change a few options and then tesat your website to see how it is effected. Use an online scanner and then check the logging file to see what WebKnight is defending against.