Preventing and Mitigating Ransomware Infections

Today I had a chance to interview the accomplished author and founder of KnowBe4, Stu Sjouwerman on the subject of Ransomware. Stu shared some great insight and real world experiences in dealing with ransomware outbreaks and the realities we’re faced with (e.g. actually paying the ransom).

If you missed it, you can view the recording for free, here:


Combining PowerShell Cmdlet Results

In my last post I used used New-Object to create an desirable output when the “Get-Mailbox” cmdlet didn’t meet my needs.  If your eyes glazed over trying to read the script, let me make it a bit simpler by focusing on a straight forward example.

Say you need to create a list of user’s mailbox size with their email address.  This sounds like a simple request, but what you’d soon find is that mailbox sizes are returned with the Get-MailboxStatistics cmdlet and the email address is not.  For that, you need to use another cmdlet, such as Get-Mailbox.

With the New-Object cmdlet, we are able to make a custom output that contains data from essentially wherever we want.

See this example:

$MyObject = New-Object PSObject -Property @{
EmailAddress = $null
MailboxSize = $null

In this example, I have created a new object with 2 fields, and saved it as the $MyObject variable.

For now, we’ve set the data to null, as shown below:


The next step is to populate each of those fields.  We can write to them one at a time with lines like this:

$MyObject.EmailAddress = (Get-Mailbox mcrowley).PrimarySmtpAddress
$MyObject.MailboxSize = (Get-MailboxStatistics mcrowley).TotalItemSize

Note: The variable we want to populate is on the left, with what we want to put in it on the right.

To confirm our results, we can simply type the variable name at the prompt:

$MyObject with data

Pretty cool, huh?

Ok, so now about that list.  My example only shows the data for mcrowley, and you probably need more than just 1 item in your report, right?

For this, you need to use the foreach loop.  You can read more about foreach here, but the actual code for our list is as follows:

(I am actually going to skip the $null attribute step here)

$UserList = Get-mailbox -Resultsize unlimited
$MasterList = @()
foreach ($User in $UserList) {
$MyObject = New-Object PSObject -Property @{
EmailAddress = (Get-Mailbox $User).PrimarySmtpAddress
MailboxSize = (Get-MailboxStatistics $User).TotalItemSize
$MasterList += $MyObject

$MasterList with data

Finally, if you wanted to make this run faster, we really don’t need to run “get-mailbox” twice.  For better results, replace the line:

EmailAddress = (Get-Mailbox $User).PrimarySmtpAddress

With this one:

EmailAddress = $User.PrimarySmtpAddress

Security Flaw in Remote Desktop

3/16/2012 UPDATE:

Exploit code published for RDP worm hole


I don’t always post on Windows security updates, but when I do, it’s a Dos Equis near to my heart!  Do you use Remote Desktop?  Of course you do.  That’s why you need to install this update immediately:

MS12-020: Vulnerabilities in Remote Desktop could allow remote code execution

This is important for anyone running just about any version of Windows, but especially if you’ve got any machine exposing Remote Desktop directly to the internet (such as a Terminal Server).  Fortunately there is a mitigation for those who just cannot patch tonight: enable NLA for your Remote Desktop connections.RDP - Network Level Authentication

Read more here.

Hop to it!  Microsoft says not to wait for a normal patch-cycle on this one…

How to Set Windows 7’s Login Wallpaper with Group Policies

With Windows XP, you could set your own login background colors and/or wallpaper by modifying the values found in the following registry location: [HKEY_USERS\.DEFAULT\Control Panel\Desktop].
Windows 7 no longer reads this registry key.  Instead you’ve got to complete the multi-step process described in this article.
Login Background for Windows XP
While the steps to set a login wallpaper are not complicated, one challenging limitation is the fact your background wallpaper needs to reside on the workstation’s hard drive.  Interestingly, this is not true for the user’s wallpaper, as there are GPO settings to point to a network location.
So when I had a customer ask me to set their login wallpaper, I had to think of how I wanted to accomplish their request.  We could possibly write a script, and as much “fun” as that might be, I’d rather use something more controlled.  Something that would allow me to easily change the configuration later as well as be decipherable to the customer after I leave.
The answer?  Group Policy – Preferences, that is!
So before we jump in to the Group Policy Management Console (GPMC), let’s identify what we’re trying to do.  If you haven’t already, you may wish to read the above link, otherwise you’re about to be lost.
We want our policy to:
  1. Copy our wallpaper file to the user’s workstation.
  2. Instruct Windows to use our file instead of the default %WinDir%\System32\oobe\background.bmp file.
With the new (ok they aren’t that new anymore) Group Policy Preferences that Windows 7 has built-in, we can copy our wallpaper to the user’s computer, while reserving the right to pull it off if the computer leaves the scope of the GPO.  To copy files, open GPMC and follow these steps:
1. Navigate to: Computer Configuration\Preferences\Windows Settings\Files clip_image001
2. Right-click the “Files” node and select:

New > File
3. Select Replace

4. Type in the UNC path for your source file.
     •In my example I used:
     •Remember this file needs to be <256K
     •Also understand the permissions on this share need to allow the workstation’s computer account READ. If you leave the usual “Authenticated Users” you’ll be fine.
5. For the Destination File, type this exact text (without the quotes, and no line breaks):
6. Click the “Common” tab

7. Select “Remove this item when it is no longer applied”. This will ensure your file is removed if:
     •The GPO is deleted or disabled
     •The workstation is moved to another OU where the policy is not linked
     •The policy is filtered out
     •You update your policy to send a new wallpaper file
8. Optionally: Select Item-level targeting to specify only Windows 7 computers. This will ensure your file isn’t sent to versions of Windows that wouldn’t make use of it anyway. clip_image005
Now we need to instruct Windows to render this image when the login screen is displayed.  If you read the above article, you’ll remember the OEMBackground registry key.  The good news is, we don’t need that key because there is actually a setting to enable it in GPMC already.
In the same Group Policy Object, navigate to:
Computer Configuration\Policies\Administrative Templates\System\Logon.
Once there, select “Always use custom logon background” and set it to “Enabled”.  This has the same effect of setting the registry manually.
Once you’ve completed these steps, close the Group Policy Management Editor and link your policy to an OU – you’re done!
This policy may take two refresh cycles (e.g. reboots) to take effect.  This is because the wallpaper file is not yet present when the “always use custom logon background” setting is first applied.  But once the file has completed copying you’ll see your image at logon.
If you would like to consider multiple screen resolutions, please consult this link.
Before we close, I should point out, this can work for Server 2008 R2 as well.  I have not tested with Vista or Server 2008.
Finally, here are some geeky, but not too over the top wallpapers:  Smile
Login Background for Windows 7

Service Pack 1 for Windows 2008 R2 Now Available for Download

Just a quick note to remind everyone that Service Pack 1 for Windows 7 and Windows 2008 R2 has just now become available for download on TechNet & MSDN.

If you don’t have a TechNet or MSDN subscription you should see it on the Microsoft Download sites next Tuesday. [EDIT: Here is the download Link]

Be sure to check with each product group before installing this.  Obviously it is supported with the OS itself (clustering, Hyper-V, RDS, etc) but you should seek a direct support statement like the one the Exchange group published.

You should also validate your 3rd party applications.  You’ll note there may be some issues with VMware, for example…

For more information such as release notes or articles on what’s new, visit this page:

Windows Server 2008 R2 Service Pack 1

Finally, here is a screenshot:

Version    6.1.7601 Service Pack 1 Build 7601

Version    6.1.7601 Service Pack 1 Build 7601

Remote Desktop Services Component Architecture Poster

Remote Desktop Services (formally Terminal Services) has dramatically improved and matured starting with the Windows 2008 launch.  In many ways, it allows Citrix installations to be replaced by native Windows technologies.

You can read more here:

This week Microsoft released a very nice diagram/poster of the technology.  Check it out here: 


Released: Active Directory Migration Tool (ADMT) version 3.2

The long awaited 2008 R2 version of ADMT has been released to the web.  You can download it here:

A good read, if you’re looking at using this tool is:

Active Directory Migration Guide


Active Directory Migration Tool (ADMT) Guide: Migrating and Restructuring Active Directory Domains

However for complex migrations/transitions/whatever I prefer the Quest Migration Manager for Active directory.

Here is some info from the ADMT download page:

The Active Directory Migration Tool version 3.2 (ADMT v3.2) provides an integrated toolset to facilitate migration and restructuring tasks in an Active Directory Domain Services infrastructure.


The Active Directory Migration Tool version 3.2 (ADMT v3.2) simplifies the process of migrating objects and restructuring tasks in an Active Directory® Domain Service (AD DS) environment. You can use ADMT v3.2 to migrate users, groups, service accounts, and computers between AD DS domains in different forests (inter-forest migration) or between AD DS domains in the same forest (intra-forest migration). ADMT can also perform security translation (to migrate local user profiles) when performing inter-forest migrations.

System Requirements
  • Supported Operating Systems: Windows Server 2008 R2
  • ADMT can be installed on any computer capable of running the Windows Server 2008 R2 operating system, unless they are Read-Only domain controllers or in a Server Core configuration.
  • Target domain: The target domain must be running Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2
  • Source domain: The source domain must be running Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2
  • The ADMT agent, installed by ADMT on computers in the source domains, can operate on computers running Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2.
Additional Information

  • PES v3.1 is a separate download also available on the Microsoft Download Center. See the Related Downloads section below.
  • ADMT v3.2 is the last version of the tool which will support migration operations involving Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2 source domains, target domains, or domain controllers.
  • To obtain customer support if you are performing migration operations involving NT 4.0 (with SP4 or higher) or Windows 2000 Server source domains, or domain controllers, please contact your Microsoft Services representative or visit

Screenshots for Windows Server 2008 R2 RTM In-Place Upgrade

One really cool benefit of being a MCT is that we get a subscription to TechNet Direct! This means I was able to get my RTM copy of Windows Server 2008 R2 earlier this afternoon!!

You can get a copy of the RTM bits yourself as a 180 trial, here.

I have a few machines that I run in my lab environment, and I figured I’d upgrade them to the latest OS so that I would have a head start for when my clients want to start installing it later this year. Many of you know the basics of installing an operating system, and I’m not going to lie – this isn’t much different than installing Server 2008, but I figured I’d document my progress and post it here for those who might benefit.

Because my lab already exists on Server 2008 SP2 Enterprise Edition x64 (you cannot upgrade from x86), I wanted to do an in-place upgrade, rather than a clean install. After doing the first machine, and gaining confidence, I moved on to the 2nd; which was my domain controller. Because I’m a little insane (& lazy), I wanted to try the upgrade via remote desktop. By golly it worked! I wouldn’t recommend this for, um, lots of reasons – but I can say it DOES work!

Before upgrading the Active Directory domain controller, I first browsed to the .\support\adprep folder and ran the following two commands:

adprep /forestprep

adprep /domainprep

These commands allow for the installation of the first 2008 R2 domain controller. Be sure to do this before you begin the upgrade routine. Active Directory is beyond the scope of what I want to cover today, but if you’re curious about adprep; more info here.

For this article, the images used are from Hyper-V (you’ll notice the window frame). This is not the computer I did remotely, but the process didn’t change.

So without further delay, here are the screenshots:

1)Run setup.exe clip_image002[4]
2)Click Install now clip_image004[4]
3)The 2008 R2 media is hot off the presses, so there is not yet any updates, but as a best practice, click “Go online to get the latest updates for installation” clip_image006[4]
4)Select the version of Windows Server 2008 R2 you wish to upgrade to.

Note: Windows 2008 R2 is x64 only. If you currently run an x86 version of Windows you will not be able upgrade.

5)Read and accept the license. clip_image010[4]
6)As I mentioned previously, I am upgrading. clip_image012[4]
7)This process ensures compatibility. More on this process here. clip_image014[4]
8)You will get a screen at the end of the previous step indicating weather or not you pass the list of known compatibility issues. This particular image (off screen) indicates I have other user accounts logged in, and they must first log out. (I had a separate RemoteApp session open).

This tool places a log file on your desktop, regardless of pass or fail so that you can review it later.

Once I closed the other sessions, I re-ran setup and was greeted with a “Next” button instead of “Close”.

9)The install begins! clip_image018[4]
10)After a while it automatically reboots the machine. From now until the end of the install it is “off” the network. clip_image020[4]
11)Setup restarts automatically clip_image022[4]clip_image024[4]
12)The installer picks up where we left off.

This is the 2nd stage of the upgrade.

13)Go find something else to do for 20 minutes. It will be fine… clip_image028[4]
14)Getting close!  clip_image030[4]
15)Almost there!  clip_image032[4]
16)Start, Run, Winver –>

(Note: Build 7600)


Once you check everything out for yourself, don’t forget to activate!  You’ve got 10 days before it starts to remind you.

And there ya have it! Happy Upgrading!

Remotely Enabling Remote Desktop (the 1337 way)

So this one is a little obscure, but lemme paint a quick picture:

A few years back, I had a small client site that had some remote users and executives that would connect to their office workstations from home via VPN / Remote Desktop.  One day an executive got a new computer and “we” forgot to enable Remote Desktop for her.  Normally this could have been addressed by a GPO, but it was a really small client site, and we just didn’t put that much complexity into the configuration.  Anyway, this same day the user wanted to work from home and she was not able to connect.  She proceeded to call me during dinner to inform me of this situation!  I wanted to help but was thinking it would be tough to allow remote access REMOTELY!  But I thought of a way!  After I completed the below steps I contacted the user and she was able to connect!

I was so proud of myself I saved the steps and now I want to share it with everyone today.  I used a combination of a free utility called psexec which can be downloaded here.  I also used the built-in command prompt and registry editor that comes with Windows.   Look at the below window, and follow the command prompt progress.  I’ve commented along the way in green.

C:\Documents and Settings\admin>”C:\Documents and Settings\admin\Desktop\psexec.exe” \\computer0123 cmd.exe


PsExec v1.94 – Execute processes remotel

Copyright (C) 2001-2008 Mark Russinovich

Sysinternals –



Microsoft Windows XP [Version 5.1.2600]

(C) Copyright 1985-2001 Microsoft Corp.




#verify hostname

C:\WINDOWS\systeadmin2>netsh firewall add portopening TCP 3389 rdp enable


#now I’m sure remote desktop will be allowed through the firewall


C:\WINDOWS\systeadmin2>netstat -a


Active Connections


  Proto  Local Address          Foreign Address        State

  TCP    computer0123:epmap  LISTENING

  TCP    computer0123:microsoft-ds  LISTENING

  TCP    computer0123:39259  LISTENING

  TCP    computer0123:netbios-ssn  LISTENING

  TCP    computer0123:netbios-ssn  LISTENING

  TCP    computer0123:microsoft-ds  ESTABLISHED

  TCP    computer0123:1332  ESTABLISHED

  TCP    computer0123:1535  ESTABLISHED

  TCP    computer0123:2033  TIME_WAIT

  TCP    computer0123:1060  LISTENING

  TCP    computer0123:10001  LISTENING

  UDP    computer0123:microsoft-ds  *:*

  UDP    computer0123:isakmp      *:*

  UDP    computer0123:1025        *:*

  UDP    computer0123:1026        *:*

  UDP    computer0123:1027        *:*

  UDP    computer0123:4500        *:*

  UDP    computer0123:ntp         *:*

  UDP    computer0123:netbios-ns  *:*

  UDP    computer0123:netbios-dgm  *:*

  UDP    computer0123:1900        *:*

  UDP    computer0123:ntp         *:*

  UDP    computer0123:netbios-ns  *:*

  UDP    computer0123:netbios-dgm  *:*

  UDP    computer0123:1900        *:*

  UDP    computer0123:ntp         *:*

  UDP    computer0123:1028        *:*

  UDP    computer0123:1044        *:*

  UDP    computer0123:1209        *:*

  UDP    computer0123:1900        *:*

#I see Remote Desktop is not enabled, as port 3389 is not in the list

#I then use regedit from my machine and remotely connect to the registry on her workstation and enable remote desktop.  (HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\fDenyTSConnection=0)


C:\WINDOWS\systeadmin2>shutdown -m \\computer0123 -r

The machine is locked and can not be shut down without the force option.


C:\WINDOWS\systeadmin2>shutdown -m \\computer0123 -r –f


C:\Documents and Settings\admin>

#it works now

For those who are lost in the command prompt, just look at these steps instead:

  1. Use psexec to open a cmd session on the computer0123 
  2. Use netsh to open a hole in the remote computer’s firewall for TCP 3389.  This is the port Remote Desktop uses.
  3.  Use netstat to check to see if remote desktop is currently listening/running
  4. Use regedit (not shown) to connect to computer0123’s registry and change the 1 to an 0 in the fDenyTSConnection key.
  5. Use the shutdown command to restart the computer, which is required when enabling Remote Desktop via the registry.