miriamxyra https://docs.microsoft.com/archive/blogs/miriamxyra/feed.xml Security blog by Miriam Wiesner, Premier Field Engineer Security @Microsoft Tue, 16 Apr 2019 06:30:10 GMT en-US hourly 1 Securing your infrastructure with Just Enough Administration https://docs.microsoft.com/archive/blogs/miriamxyra/securing-your-infrastructure-with-just-enough-administration Thu, 10 May 2018 11:41:33 GMT https://blogs.technet.microsoft.com/miriamxyra/?p=625 mx_microsoft_borderI was giving a talk about Just Enough Administration (JEA) at PSConfEU 2018 in Hannover and I also wanted to share my thoughts with you writing this blog post. My PSConfEU presentation and demo code can be found on GitHub. The recording on the session will be released soon on the official PSConfEU YouTube channel (I will update this link, once the recording of my session is released).

Current Threat Landscape

When speaking to decision makers in IT, often I hear the statement "But we are having a hardware firewall and an antivirus software! Of course we are having a good security!!!". Actually that was true fifteen years ago, but isn't anymore. Of course, firewall and antivirus vendors have secured their systems according to known threats. To breach a hardware firewall is really hard for an attacker (well, except if they have an implemented backdoor, but let's not talk about this). So attackers moved on. Most attackers choose the easy way: They don't want to spend too much resources or time, if there are easier ways to exploit. And the easiest link in the chain is the human being, so they target the identities of an organization. Once they find a way in, it takes only few hours to complete the attack, but several hundred days until they get detected. If they get detected. Often Administrators are logging on least trust systems, using less secure connection methods like RDP, leaving their credentials behind. When credentials are left behind, an attacker can easily extract them and use them to lateral move and to log in onto other systems. Most organizations also don't separate their assets and accounts into Tiers. Like this an attacker can easily escalate his privileges to finally gain access to your most valuable assets in a Windows Domain: Your domain controllers and other Tier 0 devices. Once he gained control over your DCs, he has almost complete control over your whole environment.

How can Just Enough Administration mitigate the risk?

Just Enough Administration is a PowerShell Security feature, which helps you to reduce the number of  full administrators having privileges on your systems. You define which commands your administrators are able to run and JEA enforces it for you. Cool, isn't it? And having the current threat landscape of attackers, it can also help you protecting against credential theft, if you use it wisely. As you are able to configure which accounts connect to your target system when using JEA, you can configure a virtual local account to do the work for you. So, you're not leaving your own credentials on your target machine and as this account is destroyed, once you terminate your session, it has no value to a potential attacker.

Use Cases

JEA is a great option to restrict high privileged operations which you'd like to outsource or to restrict service accounts and other users. It is also a great idea if you prevent accounts leaving their hashes behind, as either a local virtual account is used or a group managed service account. Having a local virtual account configured, the account will be destroyed, once you terminate the session. Potential use cases:
  • High privileged operations outsourced
    • Junior Administrators
    • Supporter
    • Server Operators
  • Service Accounts
  • Client Help Desk
  • Multi-Tenant Administration
  • Auditing
  • Lower trust system operations
  • Securing “in-Tier” Credentials
  • …and many more…
But please remember: JEA is not the blue pill to protect you from everything - JEA can also be bypassed, if there are vulnerabilities in your configuration. Therefore: if you outsource operations on high value systems, I'd still recommend using PAWs for performing those operations.

How does it work?

For configuring JEA, two configuration files are required:
  • Role Capability File
  • Session Configuration File

Role Capability File (= What)

In the role capability file you configure what commands can be performed by a role. You can define your own functions, define which modules are loaded and many more. You may create a skeleton Role Capability File to have a first look at the possibilities: 
New-PSRoleCapabilityFile -Path c:\JEA-Test\PSRoleCapabilityFile.psrc

Session Configuration File (= Who)

In the Session Configuration file you assign your configured Role Capability to a user or a group. You may also configure some additional session options. Create a skeleton Session Configuration File to have a look at the session configuration options: 
New-PSSessionConfigurationFile -Path c:\JEA-Test\PSSessionConfigurationFile.pssc

Registering JEA

Now that you created both configuration files (and hopefully configured a bit more than only the skeleton file), you have to register the JEA configuration to let the magic happen. You can do this either manual or via DSC. Register JEA manually (here: registering the Operator Role from my demo): 
Register-PSSessionConfiguration -Name Operator -Path "$path\Operator-SessionConfigurationFile.pssc"
After Registering, you should restart WMI for your configuration to become active: 
Restart-Service -name Winrm

Establishing a JEA connection

When registering the JEA configuration, a new session configuration is created. You may establish a remote session, but you can also connect locally via JEA: 
Enter-PSSession –ComputerName localhost –ConfigurationName Operator -Credential $DomainNetbiosName\Operator

Planning for the deployment

To implement a proper JEA configuration, you should identify which commands your users are using. In a second step you create your role capability and session configuration files to restrict your JEA pilot administrators. Deploy the configuration, test it and go back to the first step if needed - to configure even more granular commands.

Risks and misconfiguration

JEA can help you a lot to mitigate risks in your environment, but if there are flaws in your configuration, an attacker still can exploit JEA and take control over your environment. Some examples of a bad configuration:
  • Granting the connecting user admin privileges to bypass JEA
PS> Add-LocalGroupMember -Member 'CONTOSO\jdoe' -Group 'Administrators’
Add-ADGroupMember, Add-LocalGroupMember, net.exe, dsadd.exe
  • Running arbitrary code, such as malware, exploits, or custom scripts to bypass protections
PS> Start-Process -FilePath '\\san\share\malware.exe’
Start-Process, New-Service, Invoke-Item, Invoke-WmiMethod, Invoke-CimMethod, Invoke-Expression, Invoke-Command, New-ScheduledTask, Register-ScheduledJob
And, if you don't remove other connection methods like remote desktop, none of this matters as JEA restricts only your PowerShell sessions.

JEA FAQ – most common concerns

When I'm talking about JEA, most of the time I hear the same concerns:
  • Oh, it’s difficult to implement
  • …is there a GUI?
Yes it is difficult to find out who uses which commands, but I'm already working with some friends on a solution which should ease the implementation. Also feel free to submit your Role Capability Configuration on GitHub.

...is there a GUI?

For a long time, that was the point when I had to (quietly) say 'no' and move on. But with the last release of Windows Admin Center (formerly Project Honolulu), the Windows Admin Center team implemented JEA support! When I heard this, I was so euphoric and shouted out that now there is a GUI for JEA. But then I played around with Windows Admin Center and my joy faded, as there were only three predefined roles for JEA and no possibility to create custom roles. At the time of writing this article (May 2018) only those three JEA roles were implemented yet in Windows Admin Center:
  • Windows Admin Center Administrators: Allows users to view and manage most tools.
  • Windows Admin Center Hyper-V-Administrators: Allows users to manage Hyper-V virtual machines and switches. Other tools are available in read-only mode.
  • Windows Admin Center Readers: Allows users to view most tools, but doesn't allow them to make any changes.
But as I would love to have Windows Admin Center support also custom JEA roles, I created a UserVoice request: UserVoice Request for individual JEA roles in Windows Admin Center So if you also think that individual JEA roles for Windows Admin Center would be an awesome idea, I really appreciate if you could vote for my UserVoice Request. I'm looking forward to the implementation to finally provide a GUI to administrators who are not familiar using PowerShell.

Further Security Mitigations

JEA is great, but please remember that it is not the blue pill for all your security problems. To secure your infrastructure, you should also consider several other mitigations, which are also described in the Securing Privileged Access Roadmap.

But always remember...

]]> Stop using LAN Manager and NTLMv1! https://docs.microsoft.com/archive/blogs/miriamxyra/stop-using-lan-manager-and-ntlmv1 Tue, 07 Nov 2017 16:38:31 GMT https://blogs.technet.microsoft.com/miriamxyra/?p=275 What's the problem with LAN Manager? LAN Manager is the 'grandpa of authentication' in Windows Systems. It was implemented in 1987 and nowadays it is old and deprecated. And yes of course, it can be broken easily. This protocol is still used by Windows-NT based operating systems to store Password Hashes. And due to backward compatibility issues it is still in use: If a password is stored, which is shorter than fifteen Characters, a LM-Hash is generated and used. A LM-Hash is NOT case-sensitive: Before creating the hash, all characters are being casted to uppercase characters. So it does not matter if upper or lower characters were used when creating the password.

But there is also another vulnerability, caused by the first implementation of this protocol

In the earliest implementation, it was supposed that a password will never be longer than seven characters. Therefore the initial length of passwords could not exceed seven characters. Eight bytes were used to store it: seven bytes for the password plus one parity byte. When computer systems became faster and stronger, Brute-Force attacks became an issue to those "secure" eight byte passwords. They could easily be guessed, so it was decided to add more characters to the passwords. But since everyone was using a password which was generated with the old recommendations and the old protocol, the new password authentication mechanism had to be backward compatible to avoid business disruption. Therefore a new mechanism was built: eight more bytes (again seven bytes for the password, one parity byte) were added to the password to enable passwords up to fourteen characters. To maintain the usability of the old passwords, the new bytes were concatenated to the old half. Both halves were hashed and concatenated: That's how the actual LM password hash was created. It was considered that this hash will not be broken that easily. But that was not the truth...

There is still a risk after the fix

This mechanism is still risky: if a password is shorter than fourteen characters, all unfilled bytes will be filled with NULLs. So if a password is shorter than 8 characters, the second half (the new half) will remain empty and will be filled with those zero values. Both halves - again - will be hashed and concatenated. But since the second half only contains zeroes, a hash over those zeroes is created. So every time the second half is filled with zeroes, the same hash value will be used for the second part of the password. If the password is split in two halves an attacker could compare the second half with the default hash for a password containing only zeroes. If it matches, the attacker can be sure that the password has less than eight characters. Breaking the hash of the first half is easy: the attacker only needs to brute-force the eight byte hash, which can be achieved in under 6 hours.

NTLM

To understand why you should not use NTLMv1 anymore, you have to understand how this protocol works. NTLM is a challenge/response-based authentication protocol. It is the default authentication protocol of Windows NT 4.0 and earlier Windows versions.

How NTLM basically works

  1. When logging on, the client sends the plaintext user name to the server.
  2. The server generates a random number ("challenge" or "nonce") and sends it back to the client.
  3. The hash of the user's password is used to encrypt the challenge received from the server and returns the result back to the server ("response").
    • Using NTLMv1, the client takes the challenge "as it is", adds the client nonce (client nonce + server nonce), encrypts it using DES and sends it back.
    • Using NTLMv2, the client adds other parameters to the challenge: (client nonce + server nonce + time stamp + username + target) before hashing it with HMAC-MD5 and sending it back. These additional parameters protect the conversation against a replay-attack, an attack where data is repeated or delayed.
  4. The server sends the following three items to the domain controller to verify that the requesting user is allowed to log on:
    • User name
    • Challenge (which was sent to the client)
    • Response (which was received from the client)
  5. The domain controller looks up the user name and gets the corresponding password hash out of the Security Account Manager database and uses it to encrypt/hash the challenge.
  6. The domain controller compares the encrypted/hashed challenge it computed earlier with the response computed by the client. If both are identical, the authentication is successful.

Why you should not use NTLMv1 anymore...

NTLMv1 and NTLMv2 work quite similar, but the biggest difference is also the main problem why NTLMv1 should not be used anymore. The difference lies in the challenge and in the way the challenge is encrypted:
  • While NTLMv2 provides a variable-length challenge, the challenge used by NTLMv1 is always a sixteen byte random number.
  • NTLMv1 uses a weak DES algorithm to encrypt the challenge with the user's hash. DES is designed to be a very fast algorithm. But as this sounds nice at first sight, this is also the biggest weakness, because it can be also decrypted very fast.
  • NTLMv2 uses HMAC-MD5 instead. HMAC-MD5 is a bit old, but slow. So brute-forcing this encryption method is not possible at this moment (let's wait for the quantum computers...).
This leaves NTLMv1 at a high risk and therefore you should avoid using it. For NTLM authentication you should switch to NTLMv2 (even better to Kerberos) and enforce it to allow only secure authentication methods in your environment.

How to deactivate LAN Manager and NTLMv1

Please be careful when deactivating LAN Manager and NTLMv1 - really!!! Many old devices in your environment could still use those old authentication protocols. Some devices support NTLMv2, but only after configuring it on the device. So don't disable LAN Manager and NTLMv1 without knowing which devices still use it.

First step: Audit!

Prior to disabling those old authentication protocols: Listen to your devices - or better: Audit them! If you don't know which devices are relying on LAN Manager or NTLMv1, you can't disable it without crashing some of your systems.
  1. Collect Audit Logs in a central log collection.
  2. Filter for Event Logs with the Event ID 4624 - An Account was successfully logged on.
  3. In this event you will find the section "Detailed Authentication Information"
    1. If the "Authentication Package" was NTLM, NTLM was used as authentication method
    2. Now have a look at "Package Name (NTLM only)", if LM or NTLM v1 is the value of this attribute, LAN Manager or NTLMv1 was used
  4. Investigate all clients/servers where LAN Manager or NTLMv1 was used: why are they using this deprecated authentication protocol?
When you have investigated and upgraded every device to use NTLMv2, you are ready to enforce NTLMv2 globally in your environment.

Further resources on auditing and purging old authentication protocols

There are also some articles which could be really helpful when it comes to auditing and eliminating the usage of those insecure protocols. Have a look on these resources:

Enforce NTLMv2 only

So, you have audited your logon events and found out that no device is using old authentication protocols? You are ready to enforce NTLMv2? Very good! Read here how to do it. The magical key you are looking for is called LAN Manager Authentication Level. This setting defines which authentication level is used. You can either enforce it locally or via GPO:
  • Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Network security: LAN Manager authentication level
Since there are 6 levels (from 0 to 5), that means 0 is the most insecure setting, but also the default in many domains which where set up using an earlier domain level (since Windows Server 2008 the default is 3). 5 is the most restrictive and most secure level - but hard to achieve. If you want to set your LAN Manager authentication level as high as possible, start with Level 3: This level enables NTLMv2 as default, but still allows a fallback to LAN Manager and NTLMv1 in case the client is not able to use NTLMv2. Then audit, audit, audit a lot to find out which devices are still using LAN Manager and eliminate them. If there is no client/server using LAN Manager anymore, you can set the level to 4. And again: Audit, audit, audit, audit and audit once more! Is there really no device left which is using NTLMv1? Nice, you can set your LAN Manager authentication level to 5. Congratulations, you've just eliminated your old and vulnerable authentication protocols! Really good job!]]> Hello World! https://docs.microsoft.com/archive/blogs/miriamxyra/hello-world Tue, 07 Nov 2017 16:37:06 GMT https://blogs.technet.microsoft.com/miriamxyra/?p=236 Welcome to my TechNet Blog! 
Write-Host "Hello World!"

Who is writing here?

My name is Miriam Wiesner. I work at Microsoft as Premier Field Engineer, specialized on Secure Infrastructure. This is my TechNet blog, where I will post from time to time new blog posts about Security issues and helpful advice to secure your infrastructure. I also write blog posts for my private blog: my articles there do not always treat Microsoft or Security issues, but they do often. If you are interested in my other blog posts and writing, you are warmly welcomed to check it out: miriamxyra.com Prior to my work as Premier Field Engineer, I worked as Systems Administrator, Programmer, System Engineer and Consultant & Penetration Tester (I also built my own pentesting department, but that's another story).

What do I do as a Premier Field Engineer?

As a Premier Field Engineer I am mostly at customer's offices, either assessing their environment or helping them solving their security issues. Sometimes I also do a presentation if they are interested for example in new security features in the latest Windows Server release. So I travel a lot. Mostly in Germany, but also EMEA wide. Sometimes there are customers who need exactly my skillset and there is no local PFE who can help. I discover a lot of beautiful places - I never traveled that much in my life so far. While traveling I discovered a new hobby: every time I pass a Microsoft Office, I ask a colleague to take a photo in front of the building to collect photos of all the Microsoft Offices I have ever been to.
[caption id="attachment_245" align="alignnone" width="300"] Microsoft Office Munich, Germany[/caption]
[caption id="attachment_256" align="alignnone" width="202"] In front of the Microsoft Office in Bucharest, Romania[/caption]
[caption id="attachment_257" align="alignnone" width="202"] At the side entrance of Microsoft Berlin, Germany[/caption]

Where does my passion for IT security come from?

Honestly - I have no idea. Since I was a little girl, I was passionate about technology. I wanted to know how computers work. That's why I taught myself how to write code when I was 8. I was always interested in IT security, but I was not sure how to use this interest, since hacking was quite a bad thing, wasn't it? So I learned all this stuff secretly in private, hoping nobody will know (of course harming no one). Later when I already worked a few years in IT, I found out, that there actually IS a legal way to improve one's security skills. A whole IT security branch has been built during the years I worked as administrator or programmer and that there actually is a need for security experts. So I began to learn "officially" security skills, participated in CTFs, wrote articles for my blog or the Hakin9 magazine, and created hacking tutorials on YouTube (I even won a security video contest with my first video).

Enjoy my blog

However you found this blog, I hope you'll enjoy my articles. Have fun and see you around!]]>