Thanks to Jonas Lenntun from Approved Consulting AB http://www.approved.se/ in Sweden, you can now watch the recorded version of my presentation at the SCOM Days in Göteborg.

It's a 45 minute presentation about the best practices in tuning your Operations Manager Environment and your management packs.

Enjoy!

http://youtu.be/GgLkscRz6oo

And there's more coming soon - Watch this blog closely in the next months.

/Danny

What is Lateral Movement?

Lateral movement is an activity used when an attacker is scavenging a network for credentials, typically used in a Pass-The-Hash scenario.

From Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft Techniques.pdf

"In this activity, the attacker uses the credentials obtained from a compromised computer to gain access to another computer of the same value to the organization. For example, the attacker could use stolen credentials for the built-in local Administrator account from the compromised computer to gain access to another computer that has the same user name and password."

 The local accounts issue

- What's the problem with local accounts, they're local to the machine right?

Well, there is a functionality like the  "Windows for Workgroups" behaviour, inherited from previous versions of Windows, that makes local accounts a security issue. In this behaviour a client trust a local account from another machine if the password is exactly the same. This means that if you know the password of the local administrator account on one machine you could use that account to connect to other machines where the local administrator password is identically.

Normally you do not need local accounts when your machine is domain joined. You should use domain accounts instead.

How do you solve it?

One really good mitigation is to make the local administrators accounts passwords unique. Then you cannot use this account to connect to other machines.

But , how about other local accounts? Can you be sure there's no other local accounts created anywhere?

The best way is to prevent all local accounts to access other machines over the network via a group policy.

This can be done with the two new Well-known groups:

Local account S-1-5-113

All accounts in the local SAM .

Local account and member of Administrators group S-1-5-114

All accounts in the local SAM and member of the administrators Group.

How do you get these two new groups?

If you already have  Windows 8.1/Windows Server 2012 R2  they're there waiting to be used.

If you have Windows 7, Windows Server 2008 R2, Windows 8 or Windows Server 2012 machines you have to install the security update KB2871997.

This update adds the new groups among other new great security features.

Before installing KB2871997 the group list for the local administrator account will look like this:

With KB2871997 installed:

Create the Group Policy 

By adding the new group "Local Account" to the user right assignment "Deny access to this computer from the network", you deny access to the computer for local accounts over the network. Set this setting in a group policy and apply it to your machines you would like to protect. I suggest you to make sure you do not have an application relying on this old legacy behaviour before applying it to the masses.

The Result 

Local accounts will be limited to the machine where they are stored.

Perfect! They are kept right where they belongs.

Conclusion

This setting in combination with unique password and preventing local accounts from logging on using remote desktop you have relatively easy made a big impact on security!

From: Mitigating-Pass-the-Hash-Attacks-and-Other-Credential-Theft-Version-2.pdf

Overview

One of my customer was in the process of migrating away from Windows XP. As a part of this work, the customer was verifying application compatibility. During the testing of applications, they discovered that 2 applications that are business critical for the customer were having issues with file creations. These issues are counted as showstoppers for the roll out of Windows 7. The purpose of this blog is to describe the technical reasons of this issue and its resolution.

The customer´s technical issue with creating files via a web based tool with an ActiveX Component that will save information locally and Scanning Application on the client machine, focusing two specific error messages:

Error message “unable to create file” in the Scanning application

Error message “Internet explorer has had a fatal error” in the ActiveX component application

Both these application are working in Windows XP without any issues. The customer is doing a 1:1 migration of the application when they move the applications to Windows 7.

Security settings

The will give the users the same NTFS permissions as they had on Windows XP.

Based on the documentation on the applications there is a need to save temporary files in C:\. Based on this configuration shown in the Picture above, the application user will have all the necessary NTFS permission to write the application files to %systemroot%, in this case C:\.

Even though when the user is having Full Control in C:\, the user will get the access denied message.

Something strange magic is at Work here. There are more things going on than meets the eye.

The customer has high security requirements and has enabled User Account Control. One of the setting that are set is the following:

This UAC setting must be enabled for Virtual Store to be functional.

More information about this setting is available here:

http://technet.microsoft.com/en-us/library/dd851895.aspx

This means that they have enabled Virtual Stores, which means that information from the application should be written to Virtual Store directory (%LOCALAPPDATA%\VirtualStore, C:\Users\user\AppData\Local\VirtualStore).

After verifying the application we are seeing that Virtual Store is not being used.

Based on this information, we realized that we are not getting access denied when we are trying to write to C:\

As mention above in the UAC policy we should have a write failure to start the virtualization of file and registry. Without having a write failure on C:\ the Virtual Store functionality will not work.

So we have given Full Control to the user on C:\ and we have verified that the Virtual store will not be used as the user has write access to C:\.

This would mean that the user can write the temp files to C:\, but still we get Access Denied from the application.

There is another security feature at work here:

As we are trying to write to %systemroot%, the operating system will protect itself, by implementing Windows Integrity Mechanism.

Windows Integrity Mechanism is a functionality to ensure that a lower privileged process can´t alter system configuration that are critical for the operating systems.

Integrity level assignment

Based on this information we came to the conclusion that we had two processes, the ActiveX Component running in a Low Mandatory Level and the scanning application running at a Medium Mandatory Level. These applications are trying to write their temporary files to C:\, which is %systemroot%. %Systemroot% is containing several system critical files that is needed for the operating system. This means that you will need High Mandatory Level Integrity Level permission to be able to write to C:\

More information about Integrity level can be found here:

http://msdn.microsoft.com/en-us/library/bb625957.aspx

http://msdn.microsoft.com/en-us/library/bb625963.aspx

So the actual issue is that the operating system is protecting itself from having critical operating system files being altered.

Based on this information we realized that the NTFS file and folder permission are evaluated first in the perspective if the UAC configuration about Virtual Store should be used and then the Windows Integrity Level will verify if it should allow a write to %systemroot%.

This is the actual issue on why we get Access Denied even though we have given the user Full Control on C:\. The operating system is trying to protect itself from being compromised by a low privileged process!

Conclusion
 

So how did we get the application to Work?

By giving the user Read Only to C:\ we get the expected Access Denied on the write attempt on the expected C:\ folder that the application wants to do. Hence the Virtual Store will be used and the temp files are written to C:\Users\user\AppData\Local\VirtualStore, where the user has write access.

So the correct NTFS Permission for these application would be

So by giving less permission on %Systemroot% the user will get the permission to write the temporary files to the Virtual Store and the application will work again.

Sometime you probably like to re-install your system or replace a disk where you have installed Hyper-V.

In that situation you better keep track of your VMs files.

Here's a one-liner to list the location of the VM files:

get-vm * |sort-object| ft -auto Name,path,configurationlocation,snapshotfilelocation,@{L="Disks";E={$_.harddrives.path}}

I guess I'm not the only one that have been sitting and wondering .. Hmm.. What permissions does these users got in Active Directory actually? I can see a lot of groups in the access control list but how do I relate that to a certain user.

Ok, we got the Effective Rights tab under Advanced Security. But it does not show everything I expect it to do.

http://support.microsoft.com/kb/933071/en-us

I have used it from time to time and it has been a nice complement to investigating the actual permissions.

But it's hard to get a good overview of permissions, since you can't export the result or do more than one object at a time.

 To address this problem I have added more functionality to the AD ACL Scanner tool.

https://adaclscan.codeplex.com/

How to scan effective rights for a user with AD ACL Scanner:

1. Download and launch the script in Powershell.
2. Click Connect or List Domains if you would like to select and connect to another domain then you default.
3. Browse to the object you would like to scan for effective rights and select it.
4. Click on the Effective Rights tab and check "Enable Effective Rights".
5. Type the samAccountName of the user/Group or computer in the textbox. You could choose an object from a trusted domain if you first click Locations... And select the domain name.
6. Click Get Account and the Selected Security Principal field should be filled in. If you like you can take a look at all contributing memberships this account got by clicking View Account.
7. Press Run Scan to generate the report.

The result will show all permissions this account is granted through its memberships.

Why will not all Well-known SIDs be evaluated?

There are several Well-known security identifiers (SIDs) you should not expect the report to match against.

Well-known SIDs

http://msdn.microsoft.com/en-us/library/windows/desktop/aa379649(v=vs.85).aspx

2.4.2.4 Well-Known SID Structures

http://msdn.microsoft.com/en-us/library/cc980032.aspx

Why is this not in the tool?

Because first of all the account to be evaluated has to logon or be impersonated through all these scenarios to get these SIDs.

The second reason is that they are relative self explanatory. If I have granted users permissions to create group objects as a member of INTERACTIVE, they need to logon interactively
on a DC and make sure they point the tool or LDAP operation to the local machine to be able to create a group.

Well-known security identifiers (SIDs) generated at logon that is evaluated

• Everyone
• Authenticated Users
• This Organization (All accounts in all trusted forests)
• Other Organization (Accounts from an incoming domain or forest trust with Selective Authentication ) 

 If you really would like to know if a user with the Well-knonw SID  INTERACTIVE have permissions in AD you could use the filter function in AD ACL Scanner and filter for "NT AUTHORITY\INTERACTIVE" as Trustee

How to quickly determine the degree of permissions in the report?

To do that I have added a function that will mark the permissions with color codes based on the criticality of the permissions according to this table:

All you have to do is check the box "Show color coded criticality" and run a scan.

Works only for Effective Rights reports.

This is not optimal but I hope it will give you a hint on accounts with high privileges.

You have probably another view on what is critical or not depending on the situation you have.

For example I think it is more critical to create user objects than shared folder objects, since user objects are security principals.

For example I think Write Properties permissions to the Personal-Information property set would not be considered as Medium while Write Properties to pwdLastSet on user objects could be considered as critical.

I suggest all of you to create an administrtive model using Roles-Based Approach with the principle of least privilege in assigning rights and permissions.

Hopefully this tool simplify the work of building an administrative model.

 Download tool from here:

AD ACL Scanner

https://adaclscan.codeplex.com/

Suggested reading  Best Practices for Securing Active Directory