On May 31, 2022, I shared a short video on Twitter and LinkedIn showing a New-PSSession cmdlet in PowerShell that once run required the user to answer an MFA prompt. I wanted to see if there would be interest in the community in learning how this works. I am here to share that with you all. Here is the video in case you didn’t see it:
Overview and the problem
Zero Networks Access Orchestrator provides the ability to microsegment your networks and apply MFA to any network connection. In general, MFA network microsegmentation is the technique of using host level firewalls to enforce traffic control at each host, essentially turning every host into its own demilitarized zone (DMZ). This will make any attacker’s life much harder if done properly. (BTW, it is hard to do properly, future blog post on that coming soon…) To do this in any network, you must start with the host level firewall, turn on block inbound, and implicitly allow only the traffic that is needed.
There are several problems with this today. Very few organizations can implement microsegmentation due to the time-consuming nature of figuring out what is legitimate traffic on the network that should be allowed. Zero Networks helps overcome this issue, but we will cover that in a future blog. Even if an organization can microsegement the MFA network, attackers use that same legitimate traffic to laterally move inside an environment. Attackers love RDP, SSH, WinRM, WMI, etc., especially if they have credentials already. You can see this here. They also love a vulnerability that doesn’t even need credentials! The organization can’t block those ports and protocols because legitimate administrators would not be able to do their work. There are also other components that would potentially break if these were completely blocked.
This is why Zero Trust as a philosophy and a set of principles came to be. Today, many companies have created solutions to help apply Zero Trust to cloud applications or very specific ports and applications. However, this leaves every other on-prem / hybrid connection unprotected.
The solution
So how do you allow legitimate administrative network connections by applying Zero Trust principals to them? This is what Zero Networks does. We have built a way to just-in-time (JIT) any network connection by microsegmenting the network at the host firewall level. We allow the normal user traffic without breaking applications and apply MFA-based JIT access for administrative access that attackers love to use. It’s believed that MFA can stop 99.9% of attacks because the attacker needs to go through the MFA process before the network port would even be open, limiting their attack surface to… nothing. This MFA-based JIT tool stops attackers from spreading throughout the network.
In the video, I connected a PSSession to ‘ofc-hyperv’ (one of our virtualization servers). If I use Zero Networks’ free tool TrustMeter to scan that host, you can see in the screenshot below that no ports/protocols are open from the RDP server (where I ran the New-PSSession) to the Hyper-V host.
This is good! In general, you don’t want Hyper-V open on the network as attackers could use that to gain access to many VMs.
Since Hyper-V is blocked, Zero Networks will detect that and apply MFA before opening the firewall for access just in time. In our MFA policy, there are lots of options:
- Sources can be limited by user(s), group(s), asset(s) or even process(es)!
- Destinations can be selected by asset(s), group of assets, destination process and protocol/port
- One or more MFA tool methods can be chosen
- How long the rule should last
- Which ports to open, single port, all ports in the policy or just ‘Any’ port
This allows an organization to have very granular control. For our environment, we favored simplicity. This policy applies to any user doing any process on any source asset connecting via RDP (TCP 3389) or WinRM (TCP 5985) to any process on any protected asset prompt with Email, Duo Push, SMS message, and Browser. If the MFA is successful from one of those methods, open a rule for only the port that was triggered (5985 in this case) for 4 hours. We end up with an inbound allow rule that looks like the following:
Note that the rule only opened the protocol/port from a single source to the single destination and will expire in 4 hours after creation. As you saw in the video this happens in real-time, and the user doesn’t have to wait for the rule to be applied.
The Final Word
In summary, the goal of this blog was to share how attackers are still using legitimate access once they breach an environment, and yes, we all know they are breaching environments. We also showed how you can protect that legitimate access using Zero Networks MFA based JIT access to stop those attackers from spreading inside your environment.