Actively protecting pen testers and pen testing assets
Today FireEye shared that they were victim of a cyberattack and internal red teaming tooling was accessed by adversaries. More details in this NYT article.
This reminded me that I wanted to do a post on actively protecting pen testers and pen testing assets for a while.
Against persistent adversaries it is only a matter of time when they succeed, not if they will succeed. The big question is do you know when an adversary starts poking around, and when they succeed?
Here are a few things that red teamers should be aware of and consider implementing:
- Creation of honeypot machines with fake sensitive data and access notifications and alerts
- Notifications for logon attempts and logons
- Locking down machines
- Red Teaming the Red Team
Now a bit more information and details below. There is more info, multiple chapters in my red teaming book as well for anyone interested.
Honeypot files and Notifications
Red teams should create honeypot machines with fake credentials and other information and trigger notifications when/if someone starts poking around.
Notifications can be via email, like this for instance.
I also recommend sharing such events with the blue team and their central monitoring systems.
Such notifications allow your team to quickly notice when you are under attack.
Notifications for logons and logon attempts
I always recommend disabling remote management endpoints on machines.
Although sometimes it is necessary for convenience and productivity. It’s still best to allow list the source IP addresses in the firewall, rather than allowing anyone to connect.
In addition, I make sure that logon notifications are created when someone tries/or successfully logs in.
This is how it looks:
or if you are using Windows
I also recommend sending emails at the same time and forwarding events to the blue team accordingly.
Yes, the blue team is here to help the red team!
Such notifications allow to spot quickly if you under attack.
Locking down machines
I am always puzzled that many operating systems and software punch quite a lot of holes in the firewall settings. A good compromise might be to allow outbound connections on your machine. I typically entirely disable all incoming connections.
This strategy causes hiccups once in a while - so be aware that sometimes debugging and exceptions will be necessary.
Here is the netsh command for Windows to block inbound and allow outbound connections:
netsh advfirewall set allprofiles firewallpolicy blockinboundalways,allowoutbound
This changes the firewall accordingly:
Cool. The same features exist on macOS and Linux, e.g. on Linux you can use:
sudo ufw enable
sudo ufw default deny incoming
sudo ufw default allow outgoing
That’s a good baseline to have.
Red Teaming the Red Team (Red vs. Red)
If you are part of a larger organization or red team and operated for a few years, it is likely that the team has aggregated a lot of information, reports, tools and other collateral over time.
A good way to see if the red team has proper security controls and detection mechanisms in place is to perform red vs. red testing.
There are many ways this can be approached from splitting the red team into groups, leveraging external consultants or asking a peer team to assess the security posture of the red team.
Conclusions
Red teamers are prime targets for real world adversaries. Their knowledge, reports and tooling might be quite valuable for some adversaries. Be aware, assume breach.
Cheers. @wunderwuzzi23