Another quick video to show just how quickly a server can be compromised and taken over completely by an attacker.
In this video we have a server running an out of date and un-patched application, which gives the attacker a way onto the server. Then the attacker dumps and cracks the password hashes, which gives persistent remote (using ssh) access to the system. The attacker can then continue to access the server for whatever purpose they wish
Then the attacker changes the root (admin) password potentially resulting in no one else having admin access to the system. Allowing them to hold the system to ransom or threatening to take it off line to disrupt the business function, or continue to search and remove data unhindered.
This all happens in under 4 minutes. Always stay as up to date with versions and patches as possible.
This is a quick video which shows in a very basic way how important encryption is. It is important to practice defense in depth, so even if an attacker manages to gain persistence on your network and is able to “man-in-the -middle” your network connections, encryption gives another layer of protection meaning communication is not in clear text, preventing login credentials being captured.
It’s important remember, that just because an attacker has gained a foothold, does not mean they can stay there or actually do anything. It standard user permissions are well controlled, then the attacker will need to elevate their privileges. One way of doing this is capturing passwords.
The more steps an attacker needs to take to carry out their intended actions to more chance you will have to hopefully detect them on the netywork.
Here we simulate an IT engineer logging in a server terminal session, and showing how encryption protects the connection compared to telnet which communicates in clear text.
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.
Graylog recommends using Elasticsearch version 6. You can find the installation guide here if you need to refer to it, but you can install using the following. (This is not the latest version, which is not supported so don’t be tempted to try it)
Copy and paste this new hash value into the server.conf file after “root_password_sha2”
OK, so now we will be connecting to graylog over http, to be able to use https we need to configure a proxy server which wont be covered here, so always connect over a vpn if in production and you are not using https. Don’t make the web interface externally available. To configure https have a look at the docs here
Also you should enable the host firewall to only allow ports 22, 9000, and 8514, however don’t enable it yet. Get it setup and confirmed as working, then enable your firewall, as we will show later.
To configure the web interface we need to set two further options in the same server.conf file. These options are; “rest_listen_uri” and “web_listen_uri”
Get the IP of your server with the ifconfig cmd, then paste it into the location shown below and make sure the the line doesn’t have a ‘#’ at the start of the line meaning they are commented out. If the ‘#’ is there remove it. this sets both the Web interface: and REST API: options.
http_bind_address = yourIPaddress:9000/
Save and close the file. If you want more information on configuring the web interface see the documentation here
All that’s left to do is start and configure graylog to enable at startup
That’s it, give your server a restart with the following
sudo shutdown now -r
Browse to “yourIPaddress:9000/” and you should be greeted with the following login box. If not, try manually restarting all the services (mongobd, graylog and elasticsearch) using the steps through this guide and see if that resolves it. If not, you’ve done something else wrong!
Now we we know we can connect let’s enable the firewall
sudo ufw enable
And open the 2 ports we need for connecting to it
sudo ufw allow 22
sudo ufw allow 9000
You can check status as below
sudo ufw status
You can also check the status of graylog as shown below
sudo systemctl status graylog-server.service
If you have any issues you can use the following command to view the logs and look for clues.
sudo tail -f /var/log/graylog-server/server.log
Come back for the next part as we setup a complete SIEM and logging system.
I’ve been using OSSEC for a few years now and really like it. Recently while migrating my infrastructure I managed to ruin the install and so decided it would be quicker to reinstall the new version from scratch rather than repair then upgrade the existing install. This was all performed on a fresh install of ubuntu 16.04
Just note that if you wish to monitor other assets on your network you will need to set a static IP for this server. I do this using my router to set static arp entries however you can just set the server to use a static IP in the network config, but that is not covered here. Have a “duckduckgo”, there are thousands of articles telling you how to do that!
Jump onto our box, and update our repository as always.
sudo apt get update
Then we need to get the prerequesites before installing OSSEC.
sudo apt-get install build-essential
Now download the latest version to our preferred destination.
This also seemed to confirm what I suspected by di show I would need to run a cmd I’d not seen before. The solution if you’re installing as shown here is below.
sudo apt install libpcre2-dev zlib1g-dev
Once this had completed (with no further errors) I fired up the install script again, but this time included the new directive in the install script. (PCRE2_SYSTEM=yes)
sudo PCRE2_SYSTEM=yes ./install.sh
Now run through the install questions again;
Installation type – server
Where to install – use the default (just hit enter)
Email notification – y (then enter your email address and smtp details if you want to receive emails)
Run Integrity Check – y
Run rootkit detection – y
Enable firewall drop – y (you can add your IP address to the whitelist, just in case)
Hit enter – If you get any errors then most likely your build-essential has not installed correctly or you need to run through the previous section again)
Now were ready to fire up OSSEC
sudo /var/ossec/bin/ossec-control start
or check the status like this
sudo /var/ossec/bin/ossec-control status
The other thing we should do at this point is enabled the firewall and only allow the required ports. 1514 is to allow it to communicate with agents on the network that it is monitoring. 22 is to allow ssh so you can connect to the server using putty. If you don’t connect over ssh then don’t allow port 22.
sudo ufw enable
sudo ufw allow 1514/udp
sudo ufw allow 22/tcp
I also use Graylog so I need to open an additional port to allow the logs to be ingested
Excellent, so we just repeat the steps for all the versions and their dependencies
I tried to run ‘apt-get update’ but it shows the headers are still installed.
So I used the same cmd to remove the headers
sudo dpkg --purge linux-headers-4.4.0-142-generic
Then tried running “apt-get update” again, but when trying to install updates I received the same output that headers are still installed. I tried to purge again but get a dpkg error that the header is not installed. Hmmmm.
I’m not a fan of “autoremove” as I have broken many an installation using this cmd incorrectly. However as I have manually removed these I’m pretty confident it’ll be OK. I created another snapshot just to be sure, then went for it.
sudo apt autoremove
No errors, so I updated Grub next
sudo update grub
Again no errors and able to update without issues. Phew. No to carry on with what I was trying to do in the first place.
We have covered Graylog a fair bit, but to make the most of all it’s functionality we need to upgrade to an Enterprise license. Now before you start screaming “I want a FREE solution” Graylog Enterprise is free for up to 5GB of data a day, and if you are using more than that then you should be paying for it. You can use Graylog for logging without a license, however you won’t be able to make use of the Enterprise Plugins. It depends how much functionality you want from Graylog.
While the server is rebooting hopefully you should have received an email which contains instructions for getting your license key. Once you have your key you need to head back to Graylog and import our key. Go to the “Systems” Tab and select “License”. Then select the “Import New License” button and paste in your license.
You will then receive a message that your instance is activated, and your license will show under installed licenses on the same page.
That’s it, we are now licensed and ready to make full use of Graylog. Check back for the next steps of our free SIEM, and eventually adding threat feeds, and custom alerts to our Graylog server.