my personal blog about systemcenter

Adding OpenLiveWriter to a DeviceGuard Protected Machine

Categories: Device Guard, Security
Comments Off on Adding OpenLiveWriter to a DeviceGuard Protected Machine

I wanted to add OpenLiveWriter to my pc but since its protected by device guard it required a few additional steps

Following Matt Graeber (@mattifestation http://www.exploit-monday.com/2016/12/updating-device-guard-code-integrity.html guide to merging policies i ended up with the folowing

PS C:\Windows\system32> $OpenLiveWriter = Get-SystemDriver -ScanPath ‘C:\Users\FR\AppData\Local\OpenLiveWriter’ –UserPEsimage

Scanning the install directory

New-CIPolicy -FilePath OpenLiveWriter.xml -DriverFiles $OpenLiveWriter -Level PUBLISHER -UserPEs

image

“Unable to generate rules for all scanned files at the requested level.  A list of files not covered by the current policy can be found at C:\
Users\Flemming Riis\AppData\Local\Temp\tmpD089tmp.  If it is safe to not include these files, no action needs to be taken, otherwise a more c
omplete policy may be created using the -fallback switch”

image

First run was with publisher , but the majority of the files isn’t signed so i changed the policy to HASH , this laves a issue with autoupdate so the icon was changed to openlivewriter.exe instead of the update.exe

image

image

We now end up with a rather large list of allowed files

And putting it all together

$MasterRuleXml = ‘BASE.xml’ (this was my T460s baseline)

$OpenLiveWriter = Get-SystemDriver -ScanPath ‘C:\Users\FR\AppData\Local\OpenLiveWriter’ -UserPEs

New-CIPolicy -FilePath OpenLiveWriter.xml -DriverFiles $OpenLiveWriter -Level HASH -UserPEs

$OpenLiveWriterRules = New-CIPolicyRule -DriverFiles $OpenLiveWriter -Level HASH

Merge-CIPolicy -OutputFilePath FinalPolicy.xml -PolicyPaths $MasterRuleXml -Rules $OpenLiveWriterRules

ConvertFrom-CIPolicy -XmlFilePath .\FinalPolicy.xml -BinaryFilePath SIPolicy.p7b

And after a reboot i can now run openlivewriter on my device guard protected pc Smile


Count your Domain Controllers Often and Always

Categories: Active Directory, AD, Advanced Threat Analytics, ATA, Security
Comments Off on Count your Domain Controllers Often and Always

Had a talk the other day with a friend around domain controllers , we talked about how fast many orgs would actually detect a new domain controller , and if they did how fast

As this is a normal operation its not flagged by ATA , but it would be a very nice feature to add ( as far as i can see , this is a new install so no 30 days ML with admin behavior) , ATA should detect a admin logging on to a new server but need to test on a aged system

There is most likely a lot of eventlog hints of new domain controllers added need to examine for them also

image

Adding a new domain controller

image

We can see the new object as domain controller

image

Adding Domain Controllers Group to Sensitive Groups could h

image

So we could get a report like this if a DC was added could be a very good feature

image

Or list domain controllers not monitored by ATA

Detecting Domain Controllers being added

One method could be to use @LazyWinAdm 

https://github.com/lazywinadmin/Monitor-ADGroupMembership

Running

.\Monitor-ADGroupMembership.ps1 -group “Domain Controllers” -Emailfrom [email protected] -Emailto “[email protected]” -EmailServer 10.0.0.51 –Verbose

on a rapid schedule

image

image

First run find the now 2 domain controllers

image

And we will now get a email alart when a new domain controller is added or removed

Building a secure workstation one step at a time Part1

Categories: Device Guard, Security, Windows 10
Comments Off on Building a secure workstation one step at a time Part1

Been trying to spend more time on device security and have been using device guard to lock down a admin workstation and servers

I am follow the examples from Matt’s post on merging baseline with new policy’s

http://www.exploit-monday.com/2016/12/updating-device-guard-code-integrity.html

If you dont follow @mattifestation Matt Graeber start now his work published on device guard is gold

image

Code Integrity determined that a process (\Device\HarddiskVolume4\Windows\explorer.exe) attempted to load \Device\HarddiskVolume4\Source\PUTTY.EXE that did not meet the Enterprise signing level requirements.

So i wanted to add putty to my base policy

$Putty = Get-SystemDriver -ScanPath ‘C:\Source’ –UserPEs

New-CIPolicy -FilePath Putty.xml -DriverFiles $Putty -Level HASH -UserPEs

$MasterRuleXml = ‘FinalPolicy.xml’

$PuttyRules = New-CIPolicyRule -DriverFiles $Putty -Level Publisher

Merge-CIPolicy -OutputFilePath FinalPolicy_Merged.xml -PolicyPaths $MasterRuleXml -Rules $PuttyRules

ConvertFrom-CIPolicy -XmlFilePath .\FinalPolicy_Merged.xml -BinaryFilePath SIPolicy.p7b

Following the example on Matt’s blog post i wanted to try to add putty just on a file hash level , this will lock the policy down to this version only adding overhead when new released are out , but since putty isnt updated that often i will continue with file hash

It seems that going forward config manager can help with this , going to be exiting to see

This end up with the following xml that can will be merged into our policy file and applied at next reboot

<?xml version=”1.0″ encoding=”utf-8″?>
<SiPolicy xmlns=”urn:schemas-microsoft-com:sipolicy”>
   <VersionEx>10.0.0.0</VersionEx>
   <PolicyTypeID>{A244370E-44C9-4C06-B551-F6016E563076}</PolicyTypeID>
   <PlatformID>{2E07F7E4-194C-4D20-B7C9-6F44A6C5A234}</PlatformID>
   <Rules>
     <Rule>
       <Option>Enabled:Unsigned System Integrity Policy</Option>
     </Rule>
     <Rule>
       <Option>Enabled:Audit Mode</Option>
     </Rule>
     <Rule>
       <Option>Enabled:Advanced Boot Options Menu</Option>
     </Rule>
     <Rule>
       <Option>Required:Enforce Store Applications</Option>
     </Rule>
     <Rule>
       <Option>Enabled:UMCI</Option>
     </Rule>
   </Rules>
   <!–EKUS–>
   <EKUs />
   <!–File Rules–>
   <FileRules>
     <Allow ID=”ID_ALLOW_A_1″ FriendlyName=”C:\Source\PUTTY.EXE Hash Sha1″ Hash=”AB51FE77E5DB6A1979EEB6DFA6957613945F5562″ />
     <Allow ID=”ID_ALLOW_A_2″ FriendlyName=”C:\Source\PUTTY.EXE Hash Sha256″ Hash=”03EE66107D104F8ACA6E376D8B274ADF0D671A4D44F0549B6D83B775C0B21AAB” />
     <Allow ID=”ID_ALLOW_A_3″ FriendlyName=”C:\Source\PUTTY.EXE Hash Page Sha1″ Hash=”736A707BFBB80DFE3EE4259DF8BCD078B505BB4A” />
     <Allow ID=”ID_ALLOW_A_4″ FriendlyName=”C:\Source\PUTTY.EXE Hash Page Sha256″ Hash=”0843BA10DA94FC68065EA9B1FD53857106194E458FBF203948628A0EB3C539E3″ />
   </FileRules>
   <!–Signers–>
   <Signers />
   <!–Driver Signing Scenarios–>
   <SigningScenarios>
     <SigningScenario Value=”131″ ID=”ID_SIGNINGSCENARIO_DRIVERS_1″ FriendlyName=”Auto generated policy on 05-07-2017″>
       <ProductSigners />
     </SigningScenario>
     <SigningScenario Value=”12″ ID=”ID_SIGNINGSCENARIO_WINDOWS” FriendlyName=”Auto generated policy on 05-07-2017″>
       <ProductSigners>
         <FileRulesRef>
           <FileRuleRef RuleID=”ID_ALLOW_A_1″ />
           <FileRuleRef RuleID=”ID_ALLOW_A_2″ />
           <FileRuleRef RuleID=”ID_ALLOW_A_3″ />
           <FileRuleRef RuleID=”ID_ALLOW_A_4″ />
         </FileRulesRef>
       </ProductSigners>
     </SigningScenario>
   </SigningScenarios>
   <UpdatePolicySigners />
   <CiSigners />
   <HvciOptions>0</HvciOptions>
</SiPolicy>

So after reboot and policy applied

image

We now have a working putty

image

But since the author certificate wasnt whitelisted we cant run other tools , this was meant as a example on filehash vs certificate not due to lack of trust from Simon Tatham


Protecting your assets with Windows Server 2016 Device Guard Part1

Categories: AppLocker, Backup, Device Guard, Hyper-V, Security, Veeam
Comments Off on Protecting your assets with Windows Server 2016 Device Guard Part1

With Windows Server 2016 we get device guard https://www.microsoft.com/en-us/cloud-platform/windows-server-security

Enhance the protection of your applications on-premises or running in the cloud. Help ensure only trusted software runs on the server with Device Guard.

This means that we can now create policies on what are allowed to run on our servers in a more secure way than we know from applocker on desktops

In this example we have a Windows Server 2016 with Veeam installed and we want to protect against rouge applications / ransomware (this is not a veeam problem but just used as a example)

First off we block SMB in the firewall so don’t have a risk from a compromised workstation.

To get started with device guard i highly suggest the blogs from Matt Graeber @mattifestation / http://www.exploit-monday.com

A big thank you to Matt for posting his amazing content online

Windows Device Guard Code Integrity Policy Reference

http://www.exploit-monday.com/2016/12/updating-device-guard-code-integrity.html

Device Guard Code Integrity Policy Auditing Methodology

I have been following his guidelines on merging different policy’s to allow Veeam to function under the lockdown of the host

This post will show the start and the end result of the policy and additional post will show anything in between , its not a five minute now everything is working plan , there are mutiple issues with application spawning scripts and dynamic unsigned applications , but for many workloads this is very fast to get start with and give a very high return on time used

Following the procedure for whitelisting , i found that all of Veeam’s own binarys was signed with a few different certificates to they was easy to add to the policy

image

That left some files that looks to be from 3rd parties that wasn’t signed they have been added to the allow list on a file hash level , this means when there is new update our for veeam we need to add any updated files to the policy and reapply it

On the server running veeam we enabled device guard

image

Select a policy file that will be generated from the xml file with rules , from a security point of view anyone locally on the box can change the policy file so ACL needs to apply if logged on the box , or move to default system32 and for added security the policy can be signed

So with our policy applied and server rebooted , we have a functioning veeam and windows install

Now imagine a few the steps you have to go though to loose your data

1 , Logon on the veeam server

2, Open outlook is installed of some odd reason / Open webmail (if the server have internet acess for some off reason)

3,

clip_image002

Download the odd worded email , click on the hml link that downloads a zip file and have a java script inside

clip_image004

Ignore the warning and click once more

clip_image006

and a few seconds later we have encrypted all our files including the backup data (bypassing both local defender client and firewall scanning)

Again the numbers of crazy decisions you have to go though to get this far is crazy, and still we see it

So what happends on our device guard protected server

clip_image010

clip_image012

We do the same as before

clip_image008

But with a different result

clip_image016

And we can see that device guard prevented the script from running and saving the day

Protecting your secrets, one more step to remember

Categories: Active Directory, AD, Backup, Disaster Recovery, Password, TSM
Comments Off on Protecting your secrets, one more step to remember

If you are using hosted backup with TSM there is one more step to cover when people leave the org

The protection for many hosted backups are

Protection against “rouge” TSM Administrator

Client Side Encryption

Protection against “rouge” Backup Administrator

Node ID

Node Password (separation of duties one for password one for encryption)

And the last one is the issue here as its often not rotated, default TSM is 90 days but looking at different hosted TSM password is often set to no expire

This is not a TSM problem but a problem with password rotation

In the perfect world, the NodeID password and the encryption is not known by the same person, but then nodeid / password / secret is in registry so an AD admin can access this

Scenario

TSM BA Client installed on demodc01.stackdemo.dk

clip_image002

Starting the TSM client , prompting for Node Password on first backup

clip_image004

Ready for Action

clip_image006

Starting the first backup , prompts for encryption key , and after a short while the backup is completed

clip_image008

On a rouge server, outside of the environment we install the TSM BA Client and reuse the nodeID and password from the disgruntled backup admin

clip_image010

Adding the nodeid and nodepassword

clip_image012

And we restore a dummy file to see that’s its working, and is prompted for the encryption key

dsmc q b “{DEMODC01\SystemState\NULL\System State\SystemState}\ntds.dit” -sub=y

clip_image014

If we can’t remember where ntds.dit is located we can search for it

rest “{DEMODC01\SystemState\NULL\System State\SystemState}\\DEMODC01\C$|\WINDOWS\ntds\*” C:\EVILDC\ -sub=y

clip_image016

And we can restore the files

clip_image018

And we now have something we can attack , if we boot up in a winPE enviroment we can follow the procedure for system state and have a working domain controller

clip_image019

If the attacker had access to the domain controller aka disgruntled former employee the password and encryption is available on the source node in registry , since TSM used both the password and the encryption to access TSM server and backup/restore data it needs to be stored somewhere that the service can access

It’s very hard to protect anything from a domain admin even with the assume breach state of mind

clip_image021

So, we can logon without getting prompted for credentials/encryption

So what can we do

First off , prevent people from being disgruntled

And since we can’t control human nature change the password on the nodes, either scheduled or when high privilege staff leaves or both, and again the default for a TSM node is that it will be changed

clip_image023

Single Node example, log on the TSM , change password

clip_image025

Something old Something New

clip_image026

And Success , and password change can be scripted so cycling the password shouldn’t be a big issue

clip_image028

And our EvilDC can’t access TSM anymore and everything is back to normal