Tagarchief: security

A cool trick that was shown a couple of years ago, called BadUSB, turns random USB devices into possible snooping devices.

What if you plugin a USB-stick you found on the street and it turns out to open up an Internet Browser and steers you into a specific website, downloading and launching an application? USB has many profiles, so instead of a “mass storage device” (what you would expect from a USB drive that looks like an mass storage device) it imitates a HID device such as a keyboard or mouse… So your “drive” becomes a keyboard!
Automate some pre-defined keystrokes that randomly start after plugging in the USB device, like windows-logo+r, type, press enter a couple of times, and then run the same with %userprofile%\downloads\runme.exe and you’ll be pretty close running your executable without any user interaction!

Edit 26/05/2016: Exactly like this:

Not that many technologies exist to prevent this from happening on Windows though… But I found some document on irongeek explaining how to block USB devices using Group :Policy. (local policy can also be used, you don’t need to have a domainjoined computer):

Open your local policy editor, open up “Computer Configuration->Administrative Templates->System->Device Installation->Device Installation Restrictions”, and start messing around 🙂


local group policy settings

I started with checking which USB devices were already known on my computer… You can use, always awesome, nirsoft’s “USBDevview” to have a look at your USB history.

So, I deleted all history, with the idea to start clean.
After deleting everything, I let Windows re-discover all devices default to my laptop.
Next, I started plugging some USB devices I owned and let it register and install.

Then, the actual blocking policy was enabled.

Another USB-device I didn’t install for testing purposes was plugged into my computer. And nothing happened.
Perfect 😎

I still needed to install that device anyway, but starting device manager with administrative credentials, allowed me to overrule the blocking policy, and to install the USB device for future use…
(Note: once a USB device is “installed”/”registered” into windows, it can be plugged in an used anytime in the future without the admin-overrule technique…)
Or you can start defining classes of usb devices, manufacturers, etc… Just check irongeek’s page 🙂




datatraveler not being used


update driver as administrator


good to go


datatraveler active!

One of the recent security “packs” in the Microsoft ecosystem is LAPS, Local Administrator Password Solution ( It tries to solve one of the ancient issues regarding the local administrator account on a Windows machine. It needs to exists, and it needs to have , preferably, secure and unique password. Yet, in many organizations, the default administrator account is enabled, with the exact same password on every machine…
Result: once you know the password, you’re an admin on every workstation! (latteral movement) 🙂
The idea of LAPS is to randomize each password of each workstation, and store it in the Active Directory as an confidential attribute of the computer object.

LAPS can be configured to manage the local administrator account, .\administrator, or another, configurable and existing, account.


Enter MS14-025.
MS14-025 disables the usage of CPasswords in Group Policy .

This is a good thing!

CPasswords allowed unsuspicious administrators to put plaintext password in publicly-readable group policy xml-files!
(almost plaintext as the passwords are encrypted with a known password).

Here is the password btw (

 4e 99 06 e8  fc b6 6c c9  fa f4 93 10  62 0f fe e8
 f4 96 e8 06  cc 05 79 90  20 9b 09 a4  33 b6 6c 1b

Yet, this also means you cannot create a new account using Group Policy anymore.
Little “forgotten” side-effect…

And there is no real alternative to actually create a local account on a domain member…
(At installation of LAPS clientside-MSI, an argument can be set to actually create a new account…)

One way to solve this is to create a new local user is using a startup script!
The script below was tested on Windows 10, some things did break between 8.1 and 10!
Deploy it using SCCM or GPO startupscripts!

It creates an account and LAPS will change its password on first gpupdate

Note, another point of discussion is the fact whether the .\administrator should be used or not. There are a lot of different opinions here…
For LAPS, some people at Microsoft advise to “just use the .\administrator account, because you know it will always be there”. (note: account is prone to bruteforce attacks as a lockoutpolicy never applies to the rid500)
In other cases (src1, src2, src3), Microsoft advises to disable the .\administrator account, create another administrator account and use that one…
Point is, when you’re not using bitlocker, there is a tool called “Offline Windows Password & Registry Editor” by pogostick which can always enable and reset the .\administrator account’s password.
So, the choice is up to you! My humble opinion is to use another account 🙂 (otherwise I wouldn’t be going through all this trouble to get another one 🙂 )


function create-localaccount ([string]$accountName = "testuser", [string]$Computer = "localhost") {   
   $comp = [ADSI]"WinNT://$Computer"  
   $user = $comp.Create("User", $accountName)  
   $user.SetPassword(([char[]](50..150) + 0..9 | sort {get-random})[0..18] -join '') # set a random password, let it be changed by LAPS afterwards

function get-currentlocaladministrators([string]$Computer = "localhost"){
   $obj_group = [ADSI]"WinNT://$Computer/Administrators,group"
   $members= @($obj_group.psbase.Invoke("Members")) | foreach{([ADSI]$_).InvokeGet("Name")}

function add-localadministrators([string]$accountName = "testuser", [string]$Computer = "localhost"){
   $AdminGroup = [ADSI]"WinNT://$Computer/Administrators,group"
   #$User = [ADSI]"WinNT://$hostname/$accountName,user" #something broke on windows 10
   #$AdminGroup.Add($User.Path) #something broke on windows 10
   $objUser = [ADSI]("WinNT://$accountName")

get-currentlocaladministrators -Computer "localhost"
create-localaccount -Computer "localhost" -accountName "testuser"
add-localadministrators -Computer "localhost" -accountName "testuser"
get-currentlocaladministrators -Computer "localhost"

Some good LAPS references:

Quick version to improve client-side browser behaviour… (client-side best effort, so nothing is enforced…)

  • remove asp info
  • enforce https
  • specify thumbprint of known expected certificates and intermediate, and root for website
  • whitelist content security sources
  • set x-frame, aka preventing your site can be used in an iframe
  • enable xss protection
  • disable content type niffing

Add the following to your website’s web.config
(yes, web.config needs that ‘"’ around the thumbprints…)

   <remove name="X-Powered-By" />
   <add name="Strict-Transport-Security" value="max-age=31536000" />
   <add name="Public-Key-Pins" value="pin-sha256=&quot;thumbprintofcertificate1&quot;; pin-sha256=&quot;thumbprintofcertificate2-intermediate&quot;; pin-sha256=&quot;thumbprintofcertificate3-rootcert&quot;; max-age=31536000" />
   <add name="Content-Security-Policy" value="default-src https: data: 'unsafe-inline' 'unsafe-eval'" />
   <add name="X-Frame-Options" value="DENY" />
   <add name="X-Xss-Protection" value="1; mode=block" />
   <add name="X-Content-Type-Options" value="nosniff" />

Long version:

Check via



There are really some huge flaws in this system…

To bad actually, because it’s a nice thing!

Let’s show you my setup:

exe rules script rules

So everyone can run executables and scripts signed by my selfsigned codesigning certificate and the juniper ones.
Everyone can execute from %programfiles% and %windows (default rule) and Everyone from a safe directory called “epic tools” on my skydrive.
And 2 file-path exceptions for keepass and onecal…

Almost the same for powershell, with specific hash-rule for my powershellprofile (which can go now because it’s signed by the selfsigned cert)

Anyway, %desktop% is blocked for all normal users.

Bypass Applocker’s PowerShell policy

Let’s try to run a ps1 file located on the desktop.

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" "-Command" "if((Get-ExecutionPolicy ) -ne 'AllSigned') { Set-ExecutionPolicy -Scope Process Bypass }; & 'C:\Users\mendel\Desktop\applockertest\helloworld.ps1'"

I noticed this one when running a powershell script and invoking it from rightmouseclick (run with powershell) and used procmon to find the exact launch command…

(The rightmouseclick “run with powershell” is only available in the context menu if you have the “.ps1” extension associated with notepad… WTF)

And of course there are more: , .
This one is also nice!

Bypass Applocker’s exe policy

Multiple bugs/exploits for this are known. As for example the ones from Casey Smith

CaptureI just used Case’s code to PoC this 🙂

Basically, just block everything!

Device Guard

A new feature in Windows 10 might be a solution for all of this 🙂

We’ll see, we’ll see…

Ok, let’s get it over with. Once and for all a decent how-to to setup Authentication Mechanism Assurance (AMA) in Active Directory Domain Services…

The last time I talked about this, is when I just found out of it existence at techet, in a talk by Hasain Alshakarti and Marcus Murray .

It basically shows a difference in group memberships between logging in using a regular username/password , and logging in using smarcards. If you login with a password you’ll become a normal user, when you logon with a smartcard you’re an admin! 🙂

The Microsoft step-by-step guide however is a bit long, and a bit clumsy… So here a quick rewrite 🙂

➡ Required components: a Windows Server, a PKI (or the default one in ADDS whatever), and some time.

CA Templates

First, we’ll have to create a new certificate template.
Open the certificate template management console, and go to the templates.

Lets start by duplicating the “smartcard logon” one. Choose 2008R2 for everything.

This default template should be good, 1 little thing needs to change.

Open the template, go to the extensions tab. And you see the issuance policies. Here you’ll need to add a new one.

Give it some useful name, for example “server admin” or whatever.

This extra extension will now go into the actual enrolled certificate…


Next we’ll need to teach the ADDS how to map that extension to an actual Security Group. This can be done using the weird PowerShell script provided by Microsoft, but let’s do it manually here (it goes way faster!)

The link between the OID we just created and a security group is a policy defined in the regular SYSTEM partition of ADDS. Open it either using ADSIEDIT or the Sites and Services mmc.

Ofcourse we’re working with the Public Key Services, OID config, and there are all the policies stored. We’re looking for the OID of the policy we created earlier (add the “displayname” to the mmc-colums to make your life easier).

If you’ve found the correct object, rightmouseclick it, open attributes, and search for the “msDS-OIDToGroupLink” attribute.

⭐ This is the magic attribute ⭐

Fill in the DN of the security group.
And you’re good to go!


Next steps are of course the enrollment and issuance of the CA template to the correct users. But I hope you know how that works 😉
From here on you can either put it in a Virtual Smart Card, and start using it!


Password Filter

A DLL that provides password policy enforcement and change notification. The functions implemented by password filters are called by the Local Security Authority. – 
The purpose for this hook into the LSA is to create custom filters when users change password. Want some specific “default for your company” password filtered out? Want a custom RegEx next to Microsoft’s Complexity Requirements? Want to setup a real ugly sync passwords to another database? Or do you just want access to plaintext passwords? Than this is the way to go…But you can also do other stuff with it, because: “hey! a cleartext pasword!” :-p

Next piece of code doesn’t work, but also talks about the idea:
And this blogpost tries to fix what the previous one couldn’t do:

Anyway, code is visualcpp,

Most code (pretty much everyting) came from devx, who did a great job with his article: !

Next functions are called by the OS when a users changes a password:

BOOLEAN PasswordFilter(
  _In_  PUNICODE_STRING AccountName,
  _In_  PUNICODE_STRING Password,
  _In_  BOOLEAN SetOperation

NTSTATUS PasswordChangeNotify(
  _In_  ULONG RelativeId,
  _In_  PUNICODE_STRING NewPassword
BOOLEAN InitializeChangeNotify(void);


Visual studio 2013 project to download:

The only thing this code does, is write out the cleartext password to a textfile… Just a proof of concept of what you can do of course… Rest is for you guys to code 😉