Language Modes and Just Enough Administration (JEA)

We have learned that PowerShell offers amazing logging and auditing capabilities and explored how to access the local system as well as Active Directory and Azure Active Directory. We also looked at daily red and blue team practitioner tasks. In this part of the book, we are diving deeper into mitigation features and how PowerShell can help you to build a robust and more secure environment.

We will first explore language modes and understand the difference between the Constrained Language mode and Just Enough Administration (JEA). Then, we will dive deep into JEA and explore what is needed to configure your first very own JEA endpoint.

You will learn about the role capability and the session configuration file and learn how to deploy JEA in your environment. If you have the right tools at hand such as JEAnalyzer, creating an initial JEA configuration is not too hard.

Finally, you will understand how to best leverage logging...

Technical requirements

To get the most out of this chapter, ensure that you have the following:

• PowerShell 7.3 and above
• Visual Studio Code installed
• Access to the GitHub repository for Chapter10:

https://github.com/PacktPublishing/PowerShell-Automation-and-Scripting-for-Cybersecurity/tree/master/Chapter10

What are language modes within PowerShell?

A language mode in PowerShell determines which elements of PowerShell are allowed and can be used in a session. You can find out the language mode of the current session by running $ExecutionContext.SessionState.LanguageMode—of course, this only works if you are allowed to run this command:

Figure 10.1 – Querying the language mode

In the example shown in the screenshot, the Full Language mode is enabled in the current session.

There are four different language modes available, which we will explore a little bit deeper in the following sections.

Full Language (FullLanguage)

The Full Language mode is the default mode for PowerShell. Every command and all elements are allowed.

The only restrictions that a user may experience would be if they do not have the Windows privileges to run a command (such as administrative privileges), but this behavior is not restricted by language mode.

Restricted...

Understanding JEA

JEA does exactly what its name stands for: it allows you to define which role can execute which command and allows just enough administration rights.

Imagine you have multiple people working on one server system: there might be administrators and supporters who might need to perform certain operations such as restarting a service from time to time (for example, restarting the print spooler service on a print server). This operation would require administrative rights, but for the support person, an admin account would mean too many privileges—privileges that could be abused by an attacker in case the support person’s credentials get stolen.

Using JEA, the system’s administrator can define which commands can be run by a certain role and even restrict the parameters. As such, the support person can log in via PowerShell Remoting (PSRemoting), quickly restart the print spooler service, and return to their daily business. No other commands can...

Simplifying your deployment using JEAnalyzer

When I first learned about JEA, I evangelized it and told everyone how awesome this solution was. Isn’t it awesome restricting the commands your users are allowed to run to exactly to what is needed? Isn’t it amazing to configure virtual accounts and completely avoid passing the hash when using JEA and virtual accounts?

Yes, it is! But when I talked to customers about JEA and how awesome it was, I quickly received the same questions over and over again: How can we find out which commands our users and administrators are using? How can we create those role capability files in the easiest way?

And this was the time when I had the idea for the JEAnalyzer module. After I started the project, my friend Friedrich Weinmann was also very interested in this project, and when I switched jobs and barely worked with customers on other topics than Microsoft Defender for Endpoint, I was glad that he took over what I started and maintained...

Logging within JEA sessions

When using JEA, logging is of course possible, and you also should implement it and regularly review audit logs to make sure your JEA configuration is not abused in an unforeseen way.

We already covered logging extensively in Chapter 4, Detection – Auditing and Monitoring, therefore here’s only a little summary of what’s important for logging when it comes to JEA.

Over-the-shoulder transcription

Always configure over-the-shoulder transcription for users running commands via a JEA session. Over-the-shoulder transcription can be configured within the session configuration file using the TranscriptDirectory parameter, as we discussed earlier in the TranscriptDirectory section.

Make sure to protect the configured folder so that its contents cannot be manipulated by an adversary. Also forward, parse, and review the transcripts regularly.

Over-the-shoulder transcription records contain information about the user, the virtual...

Best practices – avoiding risks and possible bypasses

JEA is a great option to harden your environment and allow administrators and users to only execute the commands that they need for their daily work. But as with every other technology, JEA can also be misconfigured, and there are risks that you need to watch out for.

Do not grant the connecting user admin privileges to bypass JEA—for example, allowing commands to edit admin groups such as Add-ADGroupMember, Add-LocalGroupMember, net.exe, and dsadd.exe. Rogue administrators or accounts that were compromised could easily escalate their privileges.

Also, don’t allow users to run arbitrary code, such as malware, exploits, or custom scripts to bypass protections. Commands that you should especially watch out for are (not exclusively) Start-Process, New-Service, Invoke-Item, Invoke-WmiMethod, Invoke-CimMethod, Invoke-Expression, Invoke-Command, New-ScheduledTask, Register-ScheduledJob, and many more.

If...

Summary

In this chapter, you have learned what language modes are and how they differ from JEA. You have also learned what JEA is and how to set it up.

You now know which parameters you can use to create your own customized JEA role capability and session configuration files (or at least where to go in the book to look for them) and how to register and deploy your JEA endpoints.

Following the examples from this book’s GitHub repository, you have managed to create and explore your own JEA sessions, and you have been provided with an option on how to create a simple first configuration out of your own environment, using JEAnalyzer. Of course, you will still need to fine-tune your configuration, but the first step is done easily.

You have explored how to interpret logging files to correlate JEA sessions over different event logs and what kinds of risks to look out for when creating your JEA configurations.

JEA is a great step to define which commands can be executed...

Further reading

If you want to explore some of the topics that were mentioned in this chapter, follow these resources:

• PowerShell Constrained Language Mode: https://devblogs.microsoft.com/powershell/powershell-constrained-language-mode/
• about_Language_Modes: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_language_modes
• Just Enough Administration (official Microsoft documentation): https://docs.microsoft.com/en-us/powershell/scripting/learn/remoting/jea/overview
• JEAnalyzer on GitHub: https://github.com/PSSecTools/JEAnalyzer
• PowerShell ♥ the Blue Team: https://devblogs.microsoft.com/powershell/powershell-the-blue-team/

You can also find all links mentioned in this chapter in the GitHub repository for Chapter 10—there’s no need to manually type in every link:

https://github.com/PacktPublishing/PowerShell-Automation-and-Scripting-for-Cybersecurity/blob/master/Chapter10/Links.md