- FSLogix VHDX compaction: Resize virtual disks - Thu, Dec 1 2022
- Sysinternals Process Monitor: Real-time file system, registry, and process monitoring - Fri, Oct 28 2022
- Custom error message for access denied - Tue, Sep 27 2022
Defense in depth ^
Most enterprises today are looking at a "defense in depth" strategy. This means that there are multiple layers of protection that seek to prevent or detect intrusions within your network. Analogy-wise, it is often compared to the man who leaves his expensive watch in his clothing pocket, and it ends up broken by going through the wash. Where does the fault lie—with the person who left it there, or the person who failed to check the pockets before running it through the wash? The answer is that both have failed. And that's the idea behind defense in depth. If you have four or five mitigations in place, then you can accept a potential failure in one or two of them. The other layers of defense will cover for it.
Zero trust ^
Another popular concept we are hearing a lot more about is "zero trust." This is the idea that no user or device should ever be automatically trusted, whether inside or outside the company networks. Also, and this is often the real-world application we see, it refers to administrative accounts, and the belief that they will either be compromised or go rogue. Zero trust aims to ensure that not only do we anticipate that administrative accounts will be used in attacks, but that we have mitigations in place that can detect them and slow down the scope of their intrusion.
The problem of lateral movement ^
Lateral movement refers to the ability of an attacker who has already gained a foothold or "beachhead" in an enterprise network to pivot and extend the reach of their compromise. Moving "laterally" means moving between resources that are similar or that share underlying services. By moving laterally, they can attempt further exploits or intrusions on other devices and gain access to other more desirable resources. The exploits that they attempt when moving laterally can be a wide range of things, from human identity to unpatched vulnerabilities.
Lateral movement prevention is an important part of a defense in depth strategy. With regard to zero trust, the prevention of lateral movement often focuses on administrators, because administrators often have the ability to move laterally as part of their job. Many admin accounts (such as helpdesk) often have rights to whole swathes of workstations, which allow them to connect to user devices and assist with case closures.
What sort of lateral movement should we prevent? Obviously, connections to file servers, database servers, web servers, and the like do not really count as "lateral" movement when it comes to user applications. We are more interested in users jumping to devices of the same type, such as connecting to shares on workstations or launching RDP connections. Obviously, you need to ensure that the "upward" application traffic is genuine, but specifically with regard to stopping lateral movement, you are looking at connections to "more of the same."
In the real world, I generally start by looking at lateral connections among the workstation estate (because the laptop/desktop estate is generally where most threats gain their initial foothold, although not exclusively) from the perspective of such connections as file and printer sharing, RDP, Windows Remote Management, and the like. It's important to monitor to understand precisely how users are leveraging these kinds of technologies. When you do, you will probably be surprised at what you discover. In many enterprises I have worked in, I am often shocked to discover the amount of open RDP in use, as an example.
When you look at addressing these issues, it is always important to remember defense in depth. For instance, block WinRM by applying the policies that disable it and by blocking access to the ports. Don't forget, if a user has admin access, they can often try to override the policies in the registry and/or the port block, so not only is an in-depth approach required, but you must constantly monitor to ensure the defenses are not being shut down by creative administrators.
Mitigations you can look at to try to cut down on lateral movement include the following (not an exhaustive list, by any stretch of the imagination):
- Network segregation
- Group Policy Objects
- Password control
- Privileged access management
Network segregation ^
Each of these could comprise an article in itself. However, the point of network segregation is interesting. When it comes to dealing with privileged access, segregation means that devices that are used for "adminning" sit in a particular network segment and are the only devices that can connect to things such as WinRM, RDP, etc., on the machines in their admin scope. In an ideal world, these "administrative" network segments would also be further subdivided by role (so there would be a network segment for workstation admin, one for database admin, etc.). However, depending on the size and structure of your support teams, this may be difficult to achieve in practice. Microsoft's recommendation is to split into at least three tiers of administration, but as I said, this can sometimes be tricky to implement.
If we are going to restrict users to particular network areas to do admin tasks and separate areas to do normal day-to-day tasks, then there needs to be some change in working patterns. However, the principle is sound, as security teams can now expect administrative access from specific areas, and any deviation from this can be taken as a possible indicator of compromise. Don't forget, spotting an intrusion quickly is a key part in response to any comprise and restriction of its scope. This also means that security teams can monitor the administrative network segments and identify patterns. So maybe AdminA connects to five or six workstations via RDP every day, but if they suddenly start connecting to fifty or sixty in a short period, then that can be taken as another possible indicator of compromise. The segregation of the network cuts down on the noise and allows security to concentrate their efforts on sorting the wheat from the chaff.
Privileged access workstations ^
When we start to talk about network segregation for admin tasks, we are raising the subject of what Microsoft calls PAW. The idea is that the user has two disparate devices—one for admin work, and one for day-to-day tasks, such as email, IM, documents, web browsing, etc. There are two schools of thought on how to handle this.
The first, and the one that is likeliest to be recommended in exceptionally high-security enterprises, is that the user must use a physical device for their admin tasks; this is based on the principle of a clean source. The idea behind this is that a system can be dependent on a higher-trust system, but not a lower-trust system. If a user has a virtual machine for admin tasks, then the PAW is dependent on the security of the hypervisor and the broker provisioning it, and therefore breaks the principle. To maintain a clean source, the admin workstation should actually be the physical device in use. However, the admin user should not log on to the admin workstation using an administrative account but rather using privileged account management tools. The physical PAW should also be prevented from accessing the internet, email, or anything else that can break the clean source principle. For day-to-day work, the user would need to connect to a virtual machine of some sort.
While the most secure, this approach can often be unworkable. Especially where users are based remotely, the idea of having a dedicated workstation for administrative work can be difficult to implement, as internet access of some sort must often be allowed to simply get the PAW to connect to resources in the first place. Even if it is tightly restricted, the clean source principle has been broken. If the nature of your enterprise and working patterns mean it is not possible to provide a dedicated device in a secure area, then you need to adopt the second method, which involves using their device for day-to-day tasks and a virtual machine of some sort for administrative tasks.
In the second situation, it becomes vitally important to thoroughly secure the hypervisor and broker provisioning access to the PAW VM—and you should never use direct RDP for access. Methods of access that allow extra security controls are highly recommended, and many desktop virtualization vendors offer several features to aid with this. The virtualized PAW is without doubt an extremely high-value target, and should be additionally secured so that compromise is significantly reduced. The following list suggests some hardening procedures for the PAW VM (again, not an exhaustive list):
- The PAW should run an operating system with good security features enabled; Windows 10 provides a lot of features that can facilitate better security
- All security patches and mitigations should be promptly applied to the PAW
- Admin users should never be administrators of their own PAW
- Do not allow pass-through authentication to the PAW—users must authenticate again when they launch the PAW resource
- Ensure that endpoint MFA is also in place on the PAW
- No internet access should be allowed from the PAW
- Users must log on to the PAW using a standard user account and use a privileged account management tool (such as LAPS and/or CyberArk) to check out administrative accounts for running admin tools
- All required administrative tools should be preinstalled and secured with a whitelisting technology such as AppLocker or Windows Defender Application Control, and further segregated into access groups using FSLogix App Masking
- Command-line tools such as PowerShell should be thoroughly audited and logged into a SIEM, as well as restricted in scope where possible
- Session inactivity and disconnection limits should be very aggressive—five minutes for inactivity, and one minute for disconnection
- Cached credentials should not be stored on the PAW
- All logs from the PAW should be monitored, retained, and centrally stored, ensuring that they cannot overwrite themselves (implementing the CrashOnAuditFail feature may be necessary to ensure that event logging is never compromised)
- Regular vulnerability and malware scans should be run, and there should be several security agents installed
- All user profiles should be deleted on logoff from the PAW
- All PAWs must be fully destroyed and rebuilt every 30 days, at least
It goes without saying that applying a hardening configuration such as this has an impact on the way administrators can carry out their duties. However, it is better to sell this to the users as protection from the possible consequences of their own account being compromised rather than letting them believe it is a conscious effort to make their day-to-day job harder.
Jump servers? ^
I should note that when it comes to putting PAWs together, there is often a question of cost; this is particularly true if you are provisioning high-end virtual workstations that are heavily hardened and therefore consume more resources. While this is usually passable for higher-tier admins, users such as low-level support and helpdesk staff often just need to access one or two admin tools, and the cost of a full PAW cannot be justified.
In these cases, it can be useful to use what has traditionally been referred to as a "jump server," either providing shared desktops with a very small subset of administrative tools, or actually publishing the applications directly from the jump server. Again, access to the jump server should never be done via direct RDP, and ideally, it should be segregated from the higher-value PAWs in a tiered admin system, as described above.
Subscribe to 4sysops newsletter!
There's a lot to think about here. When it comes to consciously improving the security stance of your enterprise, concepts such as defense in depth and zero trust will be at the fore. If you adopt these—and really, you should, because the cost of a breach can be damaging on so many levels—then you will have to start looking at principles like the restriction of lateral movement, which will lead you straight to the subject of PAWs. It is a big leap, but if you set out your end goals and take a structured approach to unpicking your administrative user access and bringing it into a more compartmentalized process, you will make great strides in reducing the possibility of a damaging breach.