Exception Based Security
In the US, cigarettes, nicotine gum, and other vices typically must be purchased by talking to an employee authorized to sell the item. A minor inconvenience not aimed at stopping the sale, just controlling and discouraging who can access potentially risky vices.
Security teams can borrow from this approach by implementing exception based security where potentially risky security practices can be done, they just must ask for help (note: not permission) from someone behind the counter.
Risky actions such as deploying unmanaged devices, running outdated software, adding an unapproved browser extension, or exposing RDP to the internet should be denied by default but allowed by exception. If not, people will find a way to do them without your knowledge. Exceptions should follow the following criteria:
- If something is blocked, the process for getting an exception must be well understood.
- The exception must inform the user of why an exception is needed.
- The exception must be logged into some form of risk register
- The exception must have a compensating control. IE: Increased logging, alert priority, etc.
- The exception should be self-serve for minor exceptions.
If you think a red team is good at bypassing security controls, you should see how fast the business can bypass your entire security team because it is too restrictive. Security teams cannot stand in the way of the business, instead, they should influence the decisions made by the business to architect a structure that won’t crumble when a single crack forms.
Dartboard Security
Somewhere along my career, I encountered the term Dartboard Security. The premise was simple.
- Make a “dartboard” of all the different computers in your network.
- Throw a virtual dart at one of the computers (note: throwing physical objects at computers hard enough may technically make them impossible to hack).
- Starting from a shell on that machine, what access do you have? How can lateral movement be achieved? What security controls are in place to detect your attacks?
This exercise was described to me in the context of offensive security, but it can easily be turned into a blue team exercise by framing the questions from the opposite side. This helps avoid the bias in what you think will be attacked. If the dart lands on something seemingly inconsequential, but during the exercise you think identify that it’s actually exposed to the internet and not being scanned by your vulnerability scanning program, that’s a massive win.
Chrome Extensions Compromised
Last week, we discussed how browser extensions were ripe for abuse. On December 24th, an employee at a DLP company CyberHaven was phished. The attacker used their access to push a malicious update to the CyberHaven Chrome extension that exfiltrated authentication cookies to an attacker-controlled domain. The attack seemed to be targeting Facebook accounts. Tuckner posted a great writeup of the situation detailing how the CyberHaven attack was part of a much larger campaign with multiple other chrome extensions using similar code dating back for a few months.
Caught My Eye
- Imageless QR codes: A nifty way to bypass detections using QR codes create from HTML elements.
- Physical Exploit Kit: Nearly everything you could need for a physical pentest. If you’re buying, beware of the lead times, don’t buy a few days before your engagement.
- A deep dive into CVSS: A great overview of CVSS
- Running a production Ready Raspberry Pi Kubernetes Cluster: Self-explanatory title. Seems like a fun addition to a home lab.
- Pass A command line, gpg-based password manager that follows the Unix Philosophy. Setup guide here.
- LogonTracer: A tool to investigate malicious logon by visualizing and analyzing Windows Active Directory event logs.
- Attack Rule Map: Mapping of open-source detection rules and atomic tests.
- Notes on eBPF: eBPF is a technology I’m dying to learn more about.