Creating dynamicObjects

Auditing

Eventlog and Windows Event Forwarding

XPath Filter

<QueryList>

<Query Id="0" Path="Security">

<Select Path="Security">*[System[EventID=5136]] and *[EventData[Data[@Name='AttributeValue']='1.3.6.1.4.1.1466.101.119.2']]</Select>

</Query>

</QueryList>

• Domain Partition Node
• Configuration Partition Node
• Schema Partion Node
• AdminSDHolder
• DefaultSecurityDescriptors on objectClasses in the Schema Partition

Security issues

Attackers that try to maintain long-term persistence

Applications/Service accounts delegated too much privilege

Escalation of Privileges

How to spot the difference

What kind of permissions are more of a risk than others?

• Full Control on all objects
• Create Child Objects
  • Create new user accounts, groups etc.
  • Create dynamic objects, objects with a Time-To-Live and will disappear when TTL is meet.
• All Extended Rights
  • Password Resets
  • Replicating Directory Changes All
  • Potential access to all confidential attributes.
• Extended Right: Replicating Directory Changes All
  • This extended rights should ONLY be delegated to services that do password synchronization like the Azure AD Connect tool  or other services using DSgetNCChanges for password sync.
  • FIM/MIM does not need this permissions see: https://support.microsoft.com/en-us/kb/303972
• Reset Passwords
• Write Property to objects or sensitive attributes
  • Modify group memberships.
  • Write userPrinicpalName.
  • Write altSecIdentities
  • Write userCertificate
  • Write userAccountControl.
  • Write servicePrincipalName.
• Write Public Information
  • Includes userPrincipalName.
• Write Membership
  • Includes member and memberOf.
• Write User Account Restrictions
  • Includes userAccountControl.
• Write userPrincipalName
  • Access to modify the userPrincipalName could let someone with a valid smart card to logon as someone else by having the SubjAltName field of the smart to match another Active Directory user account.
• Write userAccountControl
  • Allow blank password.
  • Downgrade Kerberos to DES only.
  • Enable/Disable accounts.
  • Store password using reversible encryption.
• Write msDS-SupportedEncryptionTypes
  • Downgrade Kerberos encryption.
• Write Permissions
  • Replace current permissions with new more relaxed or granting access to a malicious account.
• Write servicePrincipalName
  • By adding a service principal name to an account an attacker  could potentially request a Kerberos TGS for the account and save the TGS to a file and perform offline TGS password cracking as long as RC4 Kerberos encryption is allowed.
• Take Ownership
  • Take owner ship and then replace current permissions with new more relaxed or granting access to a malicious account.
• Link Group Policy Object
  • Introduce new settings that would grant access or apply malicious code on the operating systems.

Compare the top nodes of each AD partition with the defaults

Interpreting results

Are missing permissions all bad?

What to look for?

Summary

Control Access Rights

Example:

• Account Restrictions
• DNS Host Name Attributes
• Domain Password & Lockout Policies
• General Information
• Group Membership
• Logon Information
• MS-TS-GatewayAccess
• Other Domain Parameters (for use by SAM)
• Personal Information
• Phone and Mail Options
• Private Information
• Public Information
• Remote Access Information
• Terminal Server License Server
• Web Information

Which Property Set To Use?

• employeeID
• employeeNumber
• employeeType

A month ago I reinstalled one of my PC's and thought of a project I started but never finished many years ago. It was when I found out about autorunsc.exe , one of the many awesome tools from the Sysinternals suite and the creator Mark Russinovich, when I thought of an idea to keep track of all additions to my Windows installation. Any additions to it that had any effect on my boot process or that started any processes at startup. With this information I would be able to determine when I had additions I didn’t approved nor expected.  Then I could simple remove these binaries or uninstall the guilty application.

Now, I have a slightly different approach. Besides catching all additions to the auto-runs in my Windows installation I also would like to know what executables are signed or not and if these could be a threat to me. I'm thinking of malware and vicious code. I think autorunsc.exe can do a fantastic job here with all its features, especially with some of the new features and the combination with another awesome tool, also from Sysinternals, Sigcheck.

Some  of the  things Autorunsc do:

• List all drivers, processes, scheduled tasks, boot drivers , logon startups and auto-runs.

• Check if the image of the executable is signed or not.

• Check the hash of the image.

Link to Autoruns : https://technet.microsoft.com/en-us/sysinternals/bb963902

Some  of the  things SigCheck do:

• Verify signatures.

• Check the image against Virus Total, a free online virus, malware and URL Scanner.

Link to SigCheck: https://technet.microsoft.com/en-us/sysinternals/bb897441

With a combination of both:

Scan my entire system auto-runs against Virus Total, i.e. the things Autorunsc.exe collects:

• Boot execute.

• Codecs.

• Appinit DLLs.

• Explorer addons.

• Sidebar gadgets (Vista and higher)

• Image hijacks.

• Internet Explorer addons.

• Known DLLs.

• Logon startups (this is the default).

• WMI entries.

• Winsock protocol and network providers.

• Office addins.

• Printer monitor DLLs.

• LSA security providers.

• Autostart services and non-disabled drivers.

• Scheduled tasks.

• Winlogon entries. 

Powershell - There's nothing PowerShell can't do!

Powershell comes to help once again. By using PowerShell I built a wrapper around these two Sysinternals tools (Autrunsc.exe and SigCheck.exe) plus some GUI to provide you with notifications when you got new binaries on your system.

 The processs:

• Use Scheduled Tasks to run the script at:
  • Boot(Analyze autoruns) .
  • User Logon (Notifications).

• One Powershell script that does all the job.

• The script scan the machine with Autorunsc.exe.

• Generates CSV output.

• Compares CSV inbetween boots.

• The script finds any differences.

• The script sends the user notifications when:

  • New Unsigned Non-Microsoft Binaries added.

  • New Unsigned Microsoft Binaries added.

  • Files with New Hash and  Unsigned Binaries added.

  • New Non-Microsoft Binaries added.

  • New Microsoft Binaries added.

• Provide a UI to see the added files and a summary.

• With the list of additions you can run a check against Virus Total. 

The value this script provides

• Scan the entire system auto-runs with Virus Total.

• Creates an offline file for scanning entire system auto-runs with Virus Total, when no internet is available.

• Notifications when additions to the system are added.

• A Summary of additions over every boot.

• Summary of current additions with information about what kind of modifications done. 

Requirements

These are the requirements.

• PowerShell

• Sysinternals Autorunsc v13.51 (or newer) - Autostart program viewer.

• Sysinternals Sigcheck v2.50  (or newer) - File version and signature viewer.

• Internet connection if you will run a check against Virus Total.

• Important! Once run Sigcheck -v <any file> and accept the agreement with Virus Total, if you do agree of cause :). 

• Important! Agree to Autorunsc.exe EULA.

• Important! Agree to SigCheck.exe EULA.

Run the PowerShell script once and it will prompt you with the option to agree to the EULA and to use Virus Total.

Tip! :  I would recommend the nice script Update-sysinternals.ps1 to keep your Sysinternals tools updated.

Modify the following command in the script to something like this.

Update-Sysinternalshttp -ToolsLocalDir "c:\Sysinternals"

https://gallery.technet.microsoft.com/scriptcenter/Another-Sysinternals-Tools-aa288439 

Config

To run this you have to put these two files, Autorunsc.exe and SigCheck.exe,  in a folder on your drive,  the expected path is C:\Sysinternals but it's configurable.

 1.      First run must include the "-Analyze" switch . This is needed after each boot since it will collect all auto-runs.

Verify-Autoruns.ps1 -Analyze

Or

Verify-Autoruns.ps1 -Analyze -Dir <folder path to Autorunsc.exe and SigCheck.exe>

 2.      Once we have collected data we can run the script without scanning if we just want to get notifications and summary 

Verify-Autoruns.ps1 

Or if we want notifications even if nothing has happend: 

Verify-Autoruns.ps1 -Icon 

I also suggest you put the script in the same directory, but it is not a requirement ,though it must be configured in the scheduled task. 

You can schedule a task in that runs at every boot.

This is the action for the task:

Program: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

Arguments: -ExecutionPolicy Unrestricted -File "C:\Sysinternals\Verify-Autoruns.ps1" "-Analyze"

If you want you can just import the exported Scheduled Task provided : Verify Autoruns - Analyze Boot.xml included in the attached file VerifyAutoruns_ScheduledTaskExports.zip 

You can also schedule a task in that runs at every logon to provide the user that logons with notifications.

Program: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

Arguments: -Nologo -WindowStyle Hidden -ExecutionPolicy Unrestricted -File "C:\Sysinternals\Verify-Autoruns.ps1" "-Icon"

If you want you can just import the exported Scheduled Task provided : Verify Autoruns - Verify.xml  included in the attached file VerifyAutoruns_ScheduledTaskExports.zip 

Output from Verify-Autoruns

What will this powershell script generate:

• A CSV file with all the autoruns on the system in a folder called C:\AutorunsLogs (Can be customized). Example: AutorunsC_20160210-0925.csv

Verify-Autoruns.ps1  -LogDir <folder path to all logs>

• A CSV file with any new files added . This will require that you have at least two boot scans created, there's only going to be one file for each boot. Example file: AutorunsC_New_20160210-0950.csv

• A CSV file with the collected summary of all added files, i.e. the contents of all AutorunsC_New.. files.

• SigCheck input CSV file for offline systems that can not access to internet. This file can be moved and run on internet connected systems for checking with Virus Total.

• Notifications Icon.

• Ballon Notifications.

• Report Window.

• Summary Window. 

Notifications Icon

This Shield icon in the task bar let you access three things:

• The Report Window.

• The Summary of the last run.

• Windows Reliability Monitor (This tool can provide you with events on your system that might have caused one of the additions to the auto-runs)

Balloon Notifications

The following notifications are fired at detection. This will require that you have at least two boot scans created, there's only going to be one file for each boot.

• New Non-Microsoft Files that are not signed

• Files with new Hash that are not signed

• New Microsoft files that are not signed

• New Non-Microsoft files added

• New Microsoft files added

Report Window

Here can you view the files added to autoruns. You can also:

• View a summary of the last boot.

• View the logfile.

• Check the new files against Virus Total. Requires Internet. (Requires SigCheck.exe ver 2.50 in the same  folder as Autorunsc.exe).

• Check all current autoruns against Virus Total .Requires Internet. (This might take a while).

Summary Window

This list shows the results from the latest analysis.

Virus Total Check Window

This is a table with the results from Virus Total. The column VT Detection will let you know the detection ratio. How many indications of the binary to be "unsecure" in ratio with the number of sources of information.

This picture shows the Virus Total outcome of the new addtions to Windows from the latest boot.

Scan the entire systems auto-runs against Virus Total

If you like to scan all binaries that the system runs at boot and startup you can do it from the Report Window, just click "Check All System Autoruns with Virus Total", or you can do it directly from the Powerhshell command line.

Command:

PS C:\Sysinternals> .\Verify-Autoruns.ps1 -SystemCheck 

This action might take a while since there are many files to be checked over internet. 

Or if no internet connection is possible:

 PS C:\Sysinternals> .\Verify-Autoruns.ps1 -SystemCheck -Offline

The output from this command can be used with SigChekc on a internet connected system like this:

SigCheck.exe -o -v VTInput.csv > VTResult.csv

This output will file contain the VT Detection ratio for each file. It's a CSV file that's best suitable for opening in Excel or similar.

Summary

With this script running on my PC's I can easily determine all the auto-runs added, even over time. But the coolest feature according to me is that you can scan the entire systems auto-runs against Virus Total online or offline.

This script does of course not replace any antivirus or malware software. I use it on all my PC's as an additional control and nice to have.

The script is available at TechNet Script Center here.

VerifyAutoruns_ScheduledTaskExports.zip

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

Enjoy!

https://youtu.be/GgLkscRz6oo

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

/Danny

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

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:

https://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:

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

https://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.

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}}

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.

Why will not all Well-known SIDs be evaluated?

Why is this not in the tool?

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 )

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