Linux Password Policy – Using PAM, pam_unix and pam_cracklib with Ubuntu Server 18.04.1

Linux Password Policy is often overlooked. This post is to raise awareness how we can up our game in terms of password complexity for Linux systems. Setting up password complexity in Linux specifically Ubuntu Server more specifically 18.04.1 is achieved through Pluggable Authentication Modules (PAM). To authenticate a user, an application such as ssh hands off the authentication mechanism to PAM to determine if the credentials are correct. There are various modules that can be modified within PAM to set-up aspects like password complexity and account lockout and other restrictions. We can check what modules are installed by issuing:

By default Ubuntu requires a minimum of 6 characters. In Ubuntu this is controlled by the module pam_unix which is used for traditional password authentication, this is configured in debain/ubuntu systems in the file /etc/pam.d/common-password (RedHat/Centos systems its/etc/pam.d/system-auth). Modules work in a rule/stack manner processing one rule then another depending on the control arguments. An amount of configuration can be done in the pam_unix module, however for more granular control there is another module called pam_cracklib. This allows for all the specific control that one might want for a secure complex password.

A basic set of requirements for password complexity might be:

A minimum of one upper case
A minimum of one lower case
A minimum of least one digit
A minimum of one special character
A minimum of 15 characters
Password History 15

Lets work through on a test Ubuntu 18.04.1 server how we would implement this. First install pam_cracklib, this is a ‘pluggable authentication module’ which can be used in the password stack. ‘Pam_cracklib’, will check for specific password criteria, based on default values and what you specify. For example by default it will run through a routine to see if the password is part of a dictionary and then go on to check for your specifics that you may have set like password length.

First lets install the module, it is available in the Ubuntu repository:

The install process will automatically add a line into the /etc/pam.d/common-password file that is used for the additional password control. I’ve highlight it below:

Password complexity in Linux

We can then further modify this line for additional complexity. working on the above criteria we would add:

ucredit=-1 : A minimum of one upper case
lcredit=-1 : A minimum of one lower case
dcredit=-1 : A minimum of least one digit
ocredit=-1 : A minimum of one special character
minlen=15 : A minimum of 15 characters.

note the -1 number represents a minimum value to subtract from the minlen value. There is nothing to stop you incresing this, for example ocredit=-3 would require the user to add 3 special characters.

Password history is actually controlled by pam_unix so we will touch on this separately.

Default values that get added are:

retry=3 : Prompt user at most 3 times before returning an error. The default is 1.
minlen=8 : A minimum of 15 characters.
difok=3 : The amount of character changes in the new password that differentiate it from the old password.

Our new arguments would be something like this:

For password history first we need to create a new file for pam_unix to store old passwords (hashed of course). Without this password changes will fail.

touch /etc/security/opasswd
chown root:root /etc/security/opasswd
chmod 600 /etc/security/opasswd

Add the ‘remeber=15‘ to the end of the pam_unix line and your done, at least for now. Both lines should look like this:

These changes are instant, no need to reboot or restart any service.

Now all that is left to do is test your new password policy. Whilst this does provide good password complexity I would always suggest you use a public/private key pair for SSH access and disable password authentication specifically for this service.

I hope this helps.

Facebooktwittergoogle_pluspinterestlinkedinmail

Hardening Microsoft IIS 8.5 Security Headers

In this post we will walk through how to implement some of the most common security headers that crop up in Microsoft IIS 8.5 web application testing. Typically Burp, zap nikto will highlight missing security headers. I have covered some of these for Apache in earlier posts here. Now its time for the same treatment in IIS. Some of the headers I will look at in this session are:

X-Frame-Options header – This can help prevent the clickjacking vulnerability by instructing the browser not to in bed the page in an iframe.
X-XSS-Protection header – This can help prevent some cross site scripting attacks.
X-Content-Type-Options header – This will deny content sniffing.
Content-Security-Policy – This can help prevent various attacks by telling the browser to only load content from the sources you specify. In this example I will only specify the source, ie my webpage however if you have content being pulled from youtube for example you will want to add this site also.
HTTP Strict Transport Security header – This will tell the browser to only ever load https only, once the site has been visited.

Corresponding values for the above headers are described below.

In order to lab this up we will use a vanilla Windows Server 2012 R2 server that has had the IIS role installed and configured and is serving just a simple single page running over HTTPS (only with a self signed cert for testing purposes), which looks like this:

With completely standard configuration output from Nikto would give us the following results:

OWASP Zap would give us similar results (I did this whilst still on http, however you get the idea):

Granted there is next to nothing to actually scan on this pages, however this is really only designed to demonstrate how to implement the security headers.

In the IIS console we will want to select the ‘HTTP Response Headers’, you can do this at the site level as I have done or at the webserver level which will affect all sites.

Next select Add from the left hand side:

First we will add X-XXS-Protection security header, here we can use the value of ‘1;mode=block’, this essentially means we will turn the feature on and if detected block it. Other basic options consist of ‘1’ to enable or ‘0’ to set the header however disable the feature :

Next the X-Frame-Options security header, here we can use the value of ‘DENY’ to prevent any content embedding, however this maybe too strict otherwise there is ‘SAMEORIGIN’ to allow content from your site, another option is to use ‘ALLOW-FROM’ to allow content framing from another site:

Next the X-Content-Type-Options security header, here we can use the value of ‘nosniff’:

The content security policy header, here we are specifying a very basic policy to only load content from the source:

The HTTP Strict Transport Security header, here we are setting the max age the browser should honour the header request, to include all subdomains and the preload essentially means that if HTTP site is available only load via HTTPS so on a second visit load the config first before hitting the site:

Re-running nikto gives us the following output, much better!

Hopefully this has helped harden your IIS web server just that little bit more!

 

Facebooktwittergoogle_pluspinterestlinkedinmail

Securing Domain Admins Groups in Active Directory

This is just a quick post to raise awareness of one way we can help protect our Domain Admins Group in Active Directory. I have talked previously about privilege separation and the need within the Enterprise to reduce the credential foot print of high privilege accounts. As Microsoft describes in this particular article discussing best practices, Domain Admin accounts should only be used for build and disaster recovery scenarios and should not be used for day to day activities. By following this simple rule you are mitigating against having Domain Admin credentials being cached on workstations or member servers, and therefore less likely to be dumped out of memory should the box become compromised.

We can secure the Domain Admins group for both member workstations and member servers with the following Group Policy Objects from the following user rights policy in Computer Configuration\Policies\Windows Settings\Security Settings\Local Settings\User Rights Assignments:

  • Deny access to this computer from the network
  • Deny log on as a batch job
  • Deny log on as a service
  • Deny log on locally
  • Deny log on through Remote Desktop Services user rights

Lets take a closer look and create the policy:

In our Group Policy Management console we will start off with a new policy:

Right click on the policy and click edit. Find the first policy ‘Deny access to this computer from the network’. Open it up and add the Domain Admins group to the list. Click ‘OK’.

Rinse and Repeat for the remaining policies:

Link the policy through to your computers and member workstations. Remember if your using ‘Jump boxes’ to administer your domain controllers you will need to create an exception for these and  with a different policy.

This is one small piece in a massive jigsaw of securing AD. However I hope this helps, for further reading visit https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-f–securing-domain-admins-groups-in-active-directory .

 

Facebooktwittergoogle_pluspinterestlinkedinmail

Software Restriction Policies in Microsoft Windows for basic Application White Listing.

A walk through of how we can set-up Software Restriction Policies in Microsoft Windows for basic application white listing. Software Restriction Policies have been around a while. I don’t see it being used often enough in environments considering the benefits it gives. Software restriction policies (SRP) gives us the ability to control what can be executed in certain areas of the file system. For example we can block the successfully execution of .bat file or a .exe file located on a users Desktop or Downloads folder. As you start to think about this concept more, it starts to make more sense why you would want to set this up, not only enterprise users but also for home users. When you think about malware and ‘crypto’ type ware and how easily these files are executed, blocking their execution from common folder locations makes even more sense. This is more about lessening the risk, mitigating the opportunity for unwanted binary and container files from being able to execute. SRP has been around since XP and Server 2003, it can be setup through Group Policy or alternatively for a workgroup environment you can setup on individual machines through the local policy editor in the same way as GPO. SRP could be classified as white listing and black listing. The white listing approach in my view being the more favourable. This also works as an effective control for Cyber Essentials Plus, downloading and email ingress tests.

At this point I hear many System Admins saying ‘no chance’ or ‘what a nightmare’ to configure on a large estate. To an extent there will be some pain involved in setting something like this up, needing to add exceptions for valid exe files for example may need to be made. In my view the protection of SRP far out weighs the initial pain of setting it up.

Lets have a look at how we can  go about setting up SRP in white listing mode. We will demonstrate how we can set this up in its simplest form with a basic example that you can expand upon.

First on our Domain Controller lets create a new Group Policy and find the ‘Software Restriction Policies’ folder under Computer Configuration –> Windows Settings –> Security Settings –> Software Restriction Policies like below. If you don’t have a Domain Controller we can set this up through the local security policy editor. You will notice a message in the right pane saying that no policy is defined.

Application White Listing

With the Software Restriction Policies folder selected, go ahead and select Action from the menu and select ‘New Software Restriction Policies’:

Your presented with the below:

Under ‘Security Levels’ your presented with three options:

Disallowed: This is essentially our white listing mode which blocks all be default. We then add specific unrestricted rules such as C:\Windows.
Basic User: This is essentially the same as unrestricted.
Unrestricted: This is our black listing mode which allows all be default which then allows specific rules that we want to black list.

You may initially be thinking, lets try blacklisting a few locations first ‘the least restrictive option to start with’, I believe this to be a mistake and will cause more issue later on down the road. For example if we set the security level to unrestricted, then black list the location C:\Users\John\AppData\*.exe with ‘disallowed’ you wouldn’t then be able to allow a specific valid exe from running in  C:\Users\John\AppData\Microsoft for example. In Microsoft’s world a deny trumps an allow. You would then find yourself having to block specific exe’s which is far from ideal.

White listing it is.

Moving on we can set the Security Level by right clicking on the level and selecting ‘Set as default’. Next accept the warning that will pop up, this is warning you that the level is more restrictive than the current level:

 

 

 

You should now have a small tick on Disallowed.

Lets now look at the ‘Enforcement’. Right click on Enforcement and select properties. We want to select ‘All Software files’ for maximum protection, we don’t want to just block libraries such as DLLs. In addition to this select ‘All users except local administrators’. This will allow local administrators to bypass the restriction policy, so will be able to install legitimate software when needed, by right clicking and selecting ‘Run as Administrator’ and the exe file.

Software Restriction Policies Enforcement

Next lets look at the type of files we want to guard against. Right click on ‘Designated File Types’, you can add various file types to this list, however one that we will want to remove is LNK files. Why? Well if we are looking to white list and block by default any short cut files ie .lnk files on a users desktop will not be able to execute.

Now go to additional rules.

For a basic policy that is going to make a difference start with the following rules.  The first two rules are set by default. Here we are allowing files to execute from Program files and and the Windows directory. After all we do want our users to be able to actually use the computer, right?.. files in these directories will naturally want to execute. (Remember this is just an example, in an ideal world you would go through and specify each valid exe file you want your users to be able to execute.)

Next we will apply this to a specific targeted group of computers for testing.

On our Windows 7 machine we try to execute the program ‘SolarWindds-TFTP-Server.exe’ from the desktop. This location is blocked by our policy as we selected the more restrictive mode of ‘disallow’ as the default action. We are immediately greeted by an error message explaining the exe has be blocked by policy. Great.

If we dig a little deeper, we can identify this action in the Application event log in the event viewer under event id 865, SoftwareRestrictionPolcies. This should make troubleshooting if a valid exe is being blocked significantly more easier.

So what do we do if we need to white list this exe as an example. OK so go back into our GPO settings, under additional rules we simple add a new path rule like below making it ‘Unrestricted’. Note at this point I have added a comment, this will help for auditing purposes:

If we reboot our test machine and try to execute the exe file it will now be able to execute.

As an additional example look at how we might use SRP to block a user from running cmd.exe and PowerShell.exe. Remember you will want to block ISE as well so we will block cmd.exe explicitly and the Windows PowerShell folder as a catch all. Remeber this time we are using the ‘Disallowed’ Security Level.

And here we see it in action blocking cmd.exe explicitly:

And PowerShell at the folder level in order to also block PowerShell ISE and other variants :

Careful with these two though, while it might seem immediately the right thing to do, you may run into potential login script type issues later on. Whilst this seems the right thing there are various ways of getting around these being blocked. Testing is key.

Hopefully this demonstration has shown how easy SRP can be to setup and the valuable protection it can provide. This isn’t a perfect solution by any means however will go along way to offering good sound protection to user environments for very little cost.

Facebooktwittergoogle_pluspinterestlinkedinmail

Enabling Active Directory DNS query logging

Quick Tip: Enabling Active Directory DNS query logging for Windows Server 2012 R2.

DNS query logging isn’t enabled by default in Windows Server 2012 R2 within the DNS server role. DNS ‘events’ are enabled by default just not activity events which capture lookup’s from users machine for example. This is super useful for incident response type scenarios, investigations, troubleshooting and not to mention malware or crypto type ware that’s looking to phone home to command and control. We can enable it like so:

Firstly there is a hotfix that needs to be applied to Windows Server 2012 R2 this can be found here http://support.microsoft.com/kb/2956577 you can read more about this here. This essential adds query logging and change auditing to Windows DNS servers.

Next go to the event viewer, under ‘Application and Services’, ‘Microsoft’. ‘Windows’, right click on ‘DNS-Server’ select ‘View’ following it across and select ‘Show Analystic and Debug Logs’ like below:

(Note you will actually need to left click on ‘DNS-Server’ first then right click on it otherwise the view option won’t show up.)

This will display the Analytical log, right click on this and select properties, enable logging and Do not overwrite events. Like below:

Click ok and your done.

We can verify the query logging is working in our lab by simple making a DNS request from a workstation, we will see the query in the event view under the ‘Analytical’ log like below:

Super. Now we can see which workstation IP address has made the query, and what exactly is being queried. In the above example we can see that a destination address, 10.0.2.25 a Windows 7 domain joined workstation has requested adamcouch.co.uk. Dns query Logs, yay! Hope this helps.

Facebooktwittergoogle_pluspinterestlinkedinmail

Reversing Wdigest configuration in Windows Server 2012 R2 and Windows Server 2016

Reversing wdigest configuration in Windows Server 2012 R2 and Windows Server 2016. Wdigest is an authentication protocol used in Windows. It enables the transmission of credentials across a network in MD5 format or message digest. It was designed to increase security over basic authentication initially used back in Windows Server 2003 for LDAP and Web authentication. By today’s standards, since Windows Server 2012 and Windows 8.1 Wdigest is disabled by default, the functionality was also back ported to earlier versions of windows, such as Windows 7 for you to disable via reg key. The problem with wdigest is it stores usernames and passwords in clear text. Tools such as mimikatz/wce were/are able to dump clear text passwords out from LSA  and where wdigest was used , clear text passwords would be obtained.

The question is: As this is now disabled by default can wdigest simply be enabled by attackers adding the reg key and still used to dump clear text creds?… The short answer is yes it can. See below:

The reg key to disable wdigest in earlier operating systems is: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest creating a DWORD ‘UseLogonCredential’ setting the vlaue to 0 disables it. 1 enables it.

Using a vanilla install of Windows Server 2012 R2, dumping creds we can see no clear text password is displayed in the wdigest field when running mimikatz.

Lets add the reg key and ‘Enable’ by adding a value of 1.

I immediately retried mimikatz and had the same result as before (no clear text password), I did kind of expected this however wanted to go through the motions to test. Next a log off and back on and retest. Then reboot and retest.

So, I log off and back on first:

Oh dear.

OK so what about Windows Server 2016? Lets try:

Now for the reg key, to enable :

As we know 2012 needed a log off and back on, presumably to cache the credentials, lets assume the same is needed with 2016.

Oh dear oh dear.

Ok so what can we do to prevent this. There are several methods such as, protecting the LSA and LSASS process in Windows 8.1 and Server 2012 R2 which I have talked about this here. Enabling Credential Guard, new for Windows 10 and Server 2016. Protected Users in AD. From here reducing the credential foot print of users on machines, ie blocking users from rdp’ing into other machines, disable Domain Admin’s from logging in to workstations, user a ‘Server Admins’ group instead. Having dedicated user privilege separation. Monitor for the above reg key changes. All the time we are trying to reduce the ability for an attacker to escalate privileges by dumping credentials, then moving on laterally through the network, reducing their ability to gain access to higher privilege accounts.

Facebooktwittergoogle_pluspinterestlinkedinmail

WannaCry Ransomware + MS17-010 = Cyber Attack

WannaCry – Yes you really do want to cry!

WannaCry WannaCrypt WanaCrypt0r 2.0

WannaCry is Ransomware, its also known as WannaCrypt or WanaCrypt0r 2.0 . OK so this is not a good situation if you see this, I think we will all agree. The last thing any IT Admin wants to encounter is this screen. This is where having solid backups and sound business continuity plans come into their own. The recent outbreak of WannaCry within the NHS and other private sectors companies was bad news. It put hospitals into chaos, forcing staff to resort to pen and paper.

Lets break the attack down and try to understand what has taken place. Also importantly what we can do to help protect ourselves from this.

The attack vector for this attack will have most likely been delivered via email. A phishing email attack with an attached weaponised pdf document. This then sprayed across a multitude of email accounts. The pdf attachment will have a weaponised payload that once opened will encrypt files on system. Sending the encryption/decryption key back to its Command and Control (C2 Servers). Then holding the system owner to ransom for the amount of $300, payable by bitcoin. There is no guarantee you will receive the decryption key if you do pay either. This exploit is slightly different it has been designed to propagate through networks spreading from system to system. It does this using a recent vulnerability released via the ShadowBrokers I blogged about this here. This was an NSA built tool set used by the ‘Equation Group’ threat actor,  the NSA’s Tailored Access Operations (TAO) according to Wikipedia. It would appear the ransomware WannaCry is spreading via the recent SMB vulnerability patched with MS17-010.  This was patched in April’s updates however left XP, Vista and Server 2003 vulnerable. The SMB vulnerability is giving access to the ransomware and its ability to spread very quickly from operating system to operating system. This is how the ransomware has been able to spread so quickly in such as short time frame.

In the wake of the cyber attack which occurred all over the world on Friday 12th May, Microsoft has now released patches for out of support Operating Systems. The patches are available here.  This can be imported into your WSUS or SCCM configuration ready for deployment. This means that XP and Windows Server 2003 will now be patched for the SMB vulnerability.

However there are still steps that we can follow to help prevent this from happening.

Software Updates – Patch Patch and Patch some more, can’t emphasis this enough. Ensure your patching policy is up to scratch and stick to it.

Secure configuration of SMB – Stop using SMB version 1 as describing and advised by Microsoft in this blog post.

Network Segmentation – your Client machines do not need to be in the same subnet as your Servers. Likewise your Wi-Fi clients should be separated from your internal and servers and so on. Choke points should be setup within the network to stop traffic hopping from subnet to subnet. With this Cyber attack, infected clients have been able to port scan for SMB port 445 on other devices and thus spread through the network.

Host based Firewalls – blocking access to SMB port 445 on your client machines. If SMB port 445 is needed use source port filtering to stop unwanted traffic from rogue or infected machines. Thus stopping the spreading of the malware.

Network Firewalls – Ensure your Firewalls are switched on and appropriate firewall configuration is in place. ie don’t just switch it on and allow everything through in any case.

Unsupported Software – Migrate your out of support systems XP and 2003 to new supported versions of MS Operating Systems.

User Awareness Training – Greater awarenesses training for staff. Showing and training people to be more aware when accessing Emails and the Internet.

This isn’t an exhaustive list as there are still things like Operating system hardening, network device hardening, Event Logs etc amongst just a few to work through.

Facebooktwittergoogle_pluspinterestlinkedinmail

WSUS clients not reporting in? No problem check this out.

Are you having difficulty with your WSUS clients not reporting in? I recently posted about running Microsoft Baseline Security Analyser to check your systems are getting the right patches in this post. If your haveing issues with clients not checking in this may help. If you have gone through the basic troubleshooting steps and believe you have everything in place continue on. In this instance we have recognised that our Automatic update agent store is corrupt or that your clients may have a matched susclient ID in WSUS. More info on troubleshooting the basics first can be read about in this article by Microsoft.

This script will help your clients check back in to WSUS. If the agent store is corrupt or the client agent susclient id is botched. In my experience that a few other issues this tends to be the most common issue that crops up. Issues with Clients having the Same SUSclient ID usually happens as a result of an imaging process.

Save the below txt into a batch file, then run with elevated privileges in an Administrative command prompt on your target machine.

Hope this helps as this can be frustrating waiting for clients to check back in.

Facebooktwittergoogle_pluspinterestlinkedinmail

Windows Event Forwarding – Free Tools!

Windows Event Forwarding is a powerful tool and is also free unlike most SIEM options. Being able to log certain events back to a logging server is important, getting the right events logged is also equally important, and not being swamped with the wrong events. You really do need to know if someone is messing with your Domain Admins group or an LSSAS proccess on a member server.

In this post we will walk through setting up WEF (Windows Event Forwarding) in a lab environment to demonstrate how we can have better visibility over important security events in the domain. All without having expensive SIEM products, ie using what we already have.

For a bit of background, WEF has been part of Microsoft Operating systems for a while, being supported in Windows 7 right up to 2012 R2. Events can be either source initiated, ie sent from a client, DC or member server to a collector. Alternatively be collected by the event collector server itself. The idea here being that when an important event gets written to the Windows event log (Client or Member Server) it also gets forwarded to a certal logging server and thus the IT admins or security team get alerted to the event in some manner such as email. I posted a while back about doing this for Cisco kit with a Ubuntu 14.04 server utilising rsyslog for event collection posted here. 

So our lab will utilise GNS3 as it gives us a good visual representation as to what we are working with:

WEF LAB Network Diagram

As you can see, a pretty simple lab setup a Domain Controller (DC1) a couple of member servers (NPS and WEF-Collector) and client machines (W71, W72 and W73). We won’t worry too much about ESW1 or R1 at the moment these were just left over from an 802.1x lab I had been working on, the topology is just a flat 10.0.x.x network. The events will be written to our WEF-Collector Windows Server 2012 R2 machine.

First we will setup our Event collector server WEF-Collector. We will want to ensure WinRM the Windows Remote Managment service is started and Event forwarding is setup. Open an administrative prompt and type ‘winrm qc’ (you may find it is already configured as below):

WEF WinRM qc

Now to enable event forwarding on WEF-Collector our event collector. Go to the event viewer, select ‘subscriptions’ you will get a pop up – select ‘yes’ as we do want to enable event forwarding to start automatically if the server is restarted.

WEF Event Forwarding 'Subscriptions'

Now lets look how we can forward events to the collector ‘WEF-Collector’.

First we need to give the local Network Service principal rights to read the security log, we run the following ‘wevtutil gl security’ on machine in the lab to grab the channel access string (this will be used in our GPO):

O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)

WEF Event log enable

Thanks to Jessica Payne with this article for discribing this section.

We will then append the string with (A;;0x1;;;NS) so it reads:

O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;NS)

This line is essentially where the permissions on the log are stored.

Now we will create a GPO so we can apply the settings to our clients and servers that we want to push events from, this will tell the clients and severs where to check for subscriptions and where to send events to ie ‘WEF-Collector’. We will initially want ot set two policies:

Computer Configuration>Policies>Administrative Templates>Windows Components>Event Forwarding>Configure target subscription manager:

WEF GPO Subscription Manager

Note: Instructions are in the text of the GPO iteslf however in summary we want the FQDN, URL path, port and refresh time. Clearly checking every 10 seconds is overkill however for the lab its ideal.

Computer Configuration>Policies>Administrative Templates>Windows Components>Event Log Service>Security> Configure log access:

WEF GPO Log Access

This is where our channel access string comes into play.

Our GPO should look like this:

WEF GPO Summary

Now link the GPO to our AD structure to enable it.

Now our clients and servers are configured, lets configure some example subscriptions:

Logging Domain Admin changes sounds like a good idea, this is event ID 4728 and 4729. Start in the Event View, under Subscriptions select create subscription and fill in details like so:

WEF creating subscription to monitor domain admin group changes

Next select ‘Source computer initiated’, and in this case we are going to add DC1. Next we are going to go into the Select Events option and configure like so:

At the moment we can see that DC1 hasn’t yet checked in as the ‘Source Computers’ column is still ‘0’.

Once DC1 has checked in to see if there are any subscriptiosn for it we can see that the ‘Source Computers’ column is now 1, we can check the status by clicking on ‘Runtime status’. Here we can see DC1 is ready and waiting to send events:

WEF Runtime Status

If we now generate some events on our DC by removing and adding the user ‘Bob’ to the ‘Domain Admins’ group we can see the following two events have been logged in the ‘Forward Events’ section under the ‘Windows Logs’:

Clearly this is only based on two event ID’s however hopefully demonstrates what can be done takeing this example and expanding it, creating multiple subscriptions based on certain filters and IDs.

I hope this helps demonstrate WEF and how we can get much better visualisation into whats happening on the network for security events.

Facebooktwittergoogle_pluspinterestlinkedinmail