Technical

Install RSAT on Windows 10 1809

Recently updated to Windows 10, version 1809, removed the Remote Server Administration Tools (RSAT) that were previously installed.  This is common with such updates, however, this time around I was unable to reinstall the tools.  After much digging, I discovered that this is because Microsoft has made the RSAT tools a part of the “Features on Demand” in Windows 10.

Features on Demand (FODs) are Windows feature packages that can be added at any time.
https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/features-on-demand-v2–capabilities

More info on Windows Features on Demand: https://searchwindowsserver.techtarget.com/definition/Microsoft-Windows-Features-on-Demand

To install RSAT on Windows 10 version 1809, open an elevated Command or PowerShell and run the following DISM command:

 

Once the install has completed you will notice the tools installed again under ‘Windows Administrative Tools’.

 

Here are links to additional info:

 

Veeam, vSphere 6.5, Restore job failed Error: A specified parameter was not correct: spec.vmProfile

Just a tech short on how to get past the following error: Restore job failed Error: A specified parameter was not correct: spec.vmProfile. This was encountered when testing backups via the Veeam console

This error could also be seen in vCenter

 

After some digging around I was able to get a better understanding of why it was occurring. Each time this failure would occur I would see a message “Failed to set story profile VM Encryption Policy …

But I am not using encryption policies!

This is new in vSphere 6.5 and allows for the encryption of storage where the VM would reside.
To work around this I needed to browse my datastore tree for the intended datastore rather than searching by name; What I had been previously doing.

You may see this as ‘Default policy’ container.  Select the datastore and continue as normal and you should have a successful restore.

Best of luck to you.

 

Check Point Firewall: Disconnect VPN or Mobile Access Clients

If you have a need to disconnect a user from the firewall forcibly. There are a few ways I am aware of that will force users off the VPN.

Installing Security Policy (link)-  clears the cached authentication of the remote user, although this doesn’t seem to disconnect them it prompts them to re-enter credentials.

Expire the user with SmartDashboard or change the user’s password and then push the Security Policy.

Logging into the console of the firewall and using the vpn tu command to disconnect users.
(link) – VPN Commands:  (link)

My favorite method is to SmartVire Monitor:

Open SmartView Monitor > Users > click on any of the options: Users by Gateway, Users by Name, All Users, CheckPoint Mobile Users and after finding the user you want to disconnect, right click on it and Reset Tunnel.

Windows Server 2016, AppLocker Rules

AppLocker rules can be set up by using group policy in a Windows domain and have been very useful in limiting the execution of arbitrary executable files. AppLocker takes the approach of denying all executables from running unless they have specifically been whitelisted and allowed.

AppLocker is available in Windows Desktop and Servers.  Desktop Windows require Enterprise Editions.
The AppLocker requirements can be found here.

Note:  before implementing AppLocker rules in a production environment it is important to perform thorough testing. AppLocker will not allow anything to run unless it has been explicitly whitelisted. So keep in mind those non-standard installs to the system root or other drives (C:\ or E:\).

 

AppLocker Rule Types:

  • Executable Rules: These rules apply to executables, such as .exe and .com files.
  • Windows Installer Rules: These rules apply to files used for installing programs such as .msi, .mst and .msp files.
  • Script Rules: These rules apply to scripts such as .bat, .js, .vbs, .cmd, and .ps1 files.
  • Packaged App Rules: These rules apply to the Windows applications that may be downloaded through the Windows store with the .appx extension.

With each of these rules, we can also whitelist based on the publisher, path, or file hash.

  • Publisher: This method of whitelisting items is used when creating default rules as we’ll soon see, it works based on checking the publisher of the executable and allowing this. If the publisher, file name or version etc change then the executable will no longer be allowed to run.
  • Path: Executables can be whitelisted by providing a folder path, for example, we can say that anything within C:\tools is allowed to be run by a specific active directory user group.
  • File Hash: While this may be the most secure option, it is inconvenient to work with and manage. If a file changes at all, for instance, if an executable is updated, it will not be allowed to run as the allowed hash will have changed too.

 

AppLocker Configuration:

  • Open Server Manager, selecting Tools, followed by Group Policy Management.
  • From the Group Policy Management window that opens, we’ll select the group policy objects folder within the domain, right click and select new to create a new group policy object (GPO). In this case, we’ll create one called AppLocker Rules.
  • From within the Group Policy Management Editor (GPME). Select Computer Configuration > Policies > Windows Settings > Security Settings > Applications Control Policies > AppLocker
  • In the main AppLocker interface where we can create executable, windows installer, script, and packaged app rules. We can get started with the default settings by clicking the “Configure rule enforcement”  By default each of these four items is unticked and not enabled, we can tick the box next to “Configured” to enable to set the rules to be “Enforced”.

 

 


This post is part of our Microsoft 70-744 Securing Windows Server 2016 exam study guide series. For more info: https://www.microsoft.com/en-us/learning/exam-70-744.aspx

Phishing Attacks using Office 365 and SharePoint

The bad guys are at it once again and now have a new slick way of stealing your login credentials, by sending you an invite via email to open a SharePoint document. The link(s) takes you to an actual SharePoint page where you will see a OneDrive prompt.

This prompt will have an “Access Document” link in it – don’t click this link!

This link is malicious and will take you to a fake Office 365 login screen. Any credentials you enter here will be sent to the bad guys. Don’t be tricked.

Whenever you’re submitting login credentials to any site, make sure to check the URL of the page for accuracy. Also, remember to always hover over links to see where they are taking you.

Remember, Think Before You Click.

Here’s how the Phish / Scam attack works

  • You the Friendly Office 365 user receives the malicious email –Often the use of URGENT or ACTION REQUIRED to instill a sense of immediacy to respond. The email contains a link to a SharePoint Online-based document.
  • The link directs to SharePoint – Attackers are using true-to-form SharePoint Online-based URLs, which adds credibility and legitimacy to the email and link since the user is being directed to a known-good hosting site.
  • You are then shown a OneDrive prompt – The SharePoint file impersonates a request to access a OneDrive file (again, a known cloud entity), with an “Access Document” hyperlink that is actually a malicious URL, as shown below.
  • You are then presented with an Office 365 login screen – Here is where the scam takes place. Using a very authentic-looking login page where the cybercriminals harvest the user’s credentials.

Here are is an example of a phishing email:

Just some advice – Jermal