Cyber Insecure

Today, we are going to talk a bit about the blue side, as understanding how defense works will always allow for better tactics while thinking like the bad guy. As we have already delved into the human aspect, we will remove that factor from this discussion, but only to a certain extent, as all aspects of exploitation ultimately boil down to human actions in one form or another.

The VPN:

Before I start, I want to say that this idea was inspired by OccupyTheWeb's latest video with David Bombal, as well as my direct experience in my current role. The video is attached below; please go ahead and give it a watch.

Now, what is a VPN? A VPN (Virtual Private Network) allows users to connect devices to another network that is not usually accessible via the web, using an encrypted tunnel. This is common for remote access or site-to-site connections. For a more comprehensive summary, see the article below:

What Is a Virtual Private Network (VPN)?

A virtual private network, or VPN, is an encrypted connection over the Internet from a device to a network. It is useful for corporate traffic over the Internet.

Cisco

From my experience, one of the common ways threat actors gain access is simply by compromising a company's VPN. There is no one-size-fits-all method for how this is exploited, but below are some examples:

• Vishing for access
• MFA not enabled & weak credentials allowing for brute-forcing
• Web VPN configuration with default credentials
• Phishing leading to information theft followed by access
• Unpatched firewall exploit
• Unmanaged device takeover

Following this thought, I had a great summary of where the common weaknesses reside:

• Hardware-level VPN compromises (firewall compromises) are usually the result of misconfigurations or unpatched software.
• User-level VPN compromises are usually the result of social engineering attacks.

Now, this is a broad summary based on observations and is not the set-in-stone answer to how these items occur, as edge cases and chained exploitation can occur and derail all of these ideas.

Preventative practices:

1. Keep your VPN appliances up to date.
2. Ensure your VPN appliance is configured properly:
   1. Disable unnecessary features.
   2. Remove default accounts.
   3. Disable the web portal or move it to a non-standard port.
   4. Enable lockout policies.
3. Do not allow unmanaged devices to connect to your internal network.
4. Provide end-user training.
5. Create a proper breach procedure.

Unmanaged devices:

Now, let's talk about a very double-edged subject that is one of the largest pain points when compromises occur: companies allowing unmanaged devices to access their network or their cloud environment (i.e., O365 tenant).

When I say unmanaged devices, I’m commonly referring to users' personal phones or computers that do not have any remote management or security tools installed. Now, this might be a hot take, but I strongly believe this should not be allowed, as it severely hinders visibility for the good guys and can lead to a network compromise that almost seems to occur "out of nowhere."

But will my idea ever be implemented? Most likely not, as C-suite executives, sales reps, important individuals, and the likes of want this access. Telling the CEO they cannot check their email from their own phone at 9 PM probably won’t go over too well.

But what about installing remote management software? Problem solved, right?
Technically, yes. However, I will never advocate for the removal of personal privacy. I don’t think a company should be poking around on devices you pay for and own.

Better of the two evils:

Pondering on this subject too long, the way in which I think security and privacy can be upheld with company-provided devices becomes clearer. Now, not everyone needs a phone from the company, but those who do can get one. The rest can have standardized laptops/desktops, and all company access should go through those.

Now, before someone says, "Well, if they don’t give me a phone, I won’t answer if they call me," I will say: your life, your rules. That’s a battle you can take on yourself; I will not inject my opinion into that argument.

Everyone is an administrator:

I’m not sure how else to put this, but 'Not everyone should have local admin or sudo rights on a company device.' End users do not need to be opening admin command prompts and running 'freeram_installer.exe' as admin.

This one is fairly straightforward and simple. Below are some best practices:

• Disable the local admin account.
• Do not allow local end users to be admins.
• Provide a software repository/store of approved items for users to download from.