Certutil – Verify a File Hash in Windows

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.

certutil -hashfile

This is the tool we are using and the command instruction

.\kali-Linux-2018.2-vbox-amd64.ova

This is the file we wish to hash

sha256

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!

 

Forward Windows Firewall log to Graylog (Using nxlog)

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.

Enable Windows Firewall Logging

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.

Sysmon Initial Setup

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)

cd C:\Sysmon
.\sysmon.exe

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:

.\sysmon.exe -accepteula -i sysmonconfig-export.xml

Below you can see the successful install.

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:

 

 

Forwarding Windows Event Logs into Graylog (Nxlog)

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”

Choose “Port”

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!

 

 

 

 

IIS Crypto 2.0

If you have a Microsoft Web Server and you need to disable certain Crypto suites, for example ensure that you are not using SSL 2.0 or 3.0 or DES 56/56! Then IIS Crypto is a great tool for that.

Firstly go to ssllabs and run a scan on your site.

Once you have the results if there are any encryption warnings for your site you can use IIS Crypto to resolve them.

Go to the Nartac web site and download the tool.

There is nothing to install, you just run the exe and will be greeted by this screen.

From here it is a simple checkbox exercise to enable and disable what you need. It also means that rollback is easy if you find that something broke after making changes!

To make life even easier there is a “Best Practice” setting which will disable all “broken” encrytpion methods for you.

After you have made changes just hit apply and that’s it.

You can also scan your site from within this tool. Select “Site Scanner” from the left hand menu and enter your sites URL.

This time the scan should come back with no encrytpion issues.

Till next time.

WebKnight for IIS Web Servers

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.

That’s it.

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.

Have fun.

How To Export SSL/TLS Certificate From Windows And Import To Linux

Recently I was playing around with Proxy Servers and while trying to get a HTTPS site working I needed to export my SSL Certificate from an IIS server for use on a Linux Server. Windows exports to a .pfx extension which won’t work in linux, and I would also need to extract the private key.

After a bit of googling I found the answer.

From The Windows machine.

From Start Menu click RUN then type mmc

Click FILE >> Add/Remove Snap-In

Click Certificates >> Add

Choose Computer Account

Click Next then select Local Computer and then Finish

Use + to expand the Local Computer Certificates console tree, go to the Personal directory and expand thye Certificates folder.

Right click the Certificate you need and choose All Tasks >> Export

Choose Yes, export private key and Include all certificates in certificate path if possible. (You don’t want to delete the private key unless you are SURE that you won’t need it on the server anymore. If unsure just leave it.)

Leave all other settings, and set a password. (don’t forget it!)

Save the .pfx file in your chosen location.

Now to import to Linux

Copy the .pfx file over to your Linux Server using your preferred method.

Then run the following commands. (using your file name in place of “yourcertfile”)

sudo openssl pkcs12 -in yourcertfile.pfx -clcerts nokeys -out newcertfile.cer

sudo openssl pkcs12 -in yourcertfile.pfx -nocerts -nodes -out newkeyfile.key

Now you have 2 new files, one .cer which  is your certificate, and a .key which is your private key file.

Last thing is to delete the .pfx file from the Linux server. You don’t want copies of this lying around if they aren’t needed. If you do need to keep a copy, then copy it onto an encrypted USB and keep it safe.

To delete from your Linux server, from the directory it is located just use

sudo rm yourcertfile.pfx 

You’re done.

 

Exchange 2016. New Install Issues.

Recently I did a test install of Exchange 2016 and ran into a few problems which drove me mad for a while as the issues and symptoms did not give any clue as to how they were eventually resolved!

I did a fresh install on a stand alone Hyper-V Virtual Server with 4000 GB of static RAM, 4 processor cores and a 40GB VHD.

Microsoft recommends a minimum of 8GB for mailbox role, (see here) but I couldn’t believe it would actually need this much on a test Server, and I’ve always used way less than the recommended for initial test installs as they will be under no stress at all.

The install seemed to go fine, all the prerequestites were installed by the downloaded media, and the server restarted. On trying the open the webpanel I was continually told that there was a memory error, and to try again later. I ramped up the RAM 1GB at a time but I couldn’t login to the panel until the Server had the full 8GB assigned.

After creating my first test mailbox whenever I tried to send an email I received the below error:

“You don’t have permission”? WTF after going round and round in circles looking at users permissions believing that I needed to assign user permissions I found an obscure forum post which pointed me in the right direction. The solution was to remove the secondary DNS entry from the Exchange Servers network adapter! After removing this and then restarting the server the error disappeared.

I was now able to login and send emails internally and externally, however I was not able to receive emails either internal or external. I wasn’t getting any bouncebacks which could have given me some information on what was going on, I double checked my external DNS and MX records but all were correct.

In the end I used the Microsoft Connectivity Tool and this pointed out my issue immediately, and the issue was disk space. Even though the Exchange server had only 1 mailbox and nothing else installed, 40GB wasn’t enough! I checked disk space and there was plenty of room, but after digging a bit deeper it turns out that Exchange needs a percentage of free disk space and so the VHD had to be expanded. Once this was increased I finally had a working Exchange Server. Hope this helps out someone else as this drove me crazy for a few hours and the errors were not pointing me in the right direction.