Ok so my most popular blog on pwndefend is about using Hydra… so I guess that’s all the goodies using it for good things, right? Probably not but it does help people understand the weaknesses of single factor authentication systems without supplementary controls.

So, let’s look at authentication defences, but let’s do this from an attacker perspective! (The opposite of what helps an attacker usually helps defend). Crazy madness right, let’s get to it!

Foundations of Sand

Ok so authentication is a key security control in computer systems. To understand the challenge around authentication and think it’s all a technical problem is to error.

See most modern computer systems require at least two things to authenticate:

• A Username
• A Password

Together these make up the two things you need to know to access the majority of computer systems.

A major challenge here is that usernames are often easy to enumerate or guess. The second part is even harder, the next 50% often has been generated by a human. On top of this the INFOSEC industry for years was giving out really bad password guidance advice! How about that!

What went wrong? Well back in the dark ages of IT people had very weak passwords, default credentials were all over the place and people’s passwords were silly like “monkey” or “iloveyou”. (Ok, no shit, they still are silly in 2021 as well)

Now the “security experts” decided that to solve this problem we should implement password policies that overcomes this by making people:

• Change passwords every 30 days
• Make them use 8-character passwords at minimum
• Enforcing using complexity requirements

Now we went from “monkey” to “Winer2021!”

Wow much strong so secure!

There is a huge human factor to consider with passwords (yes, I know we should be using MFA and/or password less auth etc. more on that later) so let’s think about how we combat this without deploying more modern authentication systems.

Thinking like a baddie

Ok if we were to attack an authentication system directly without looking for weaknesses in our authentication design/method/process where would we attack?

Well, let’s think about this:

We first want to enumerate people’s details (usernames, names, personal info etc.) we can do this using a combination of OSINT and technical techniques.

So, we want to get:

• Common names
• Common default usernames
• Specific intelligence about the target organisation and its supply chain (yes this is important as well)

So, for now let’s assume we are a cunning and motivated attacker, and we have a list of usernames.

Now let’s think about password-based attacks. The first thing we should think of is looking at social engineering (phishing, smishing, vishing etc.). To defend against these, we need to have smart cookies who are aware of threats alongside some technical controls. That however isn’t for this post. We are going to assume that our Social Engineering attacks failed. But we do have however an exposed service that we can authenticate to over the internet.

To attack this service where we have a known set of usernames, we are going to look at developing our next dataset, passwords.

• We are going to look to grab credentials from previous breaches (credential stuffing)
• We are going to generate wordlists based on the company metadata (crawling their website etc)
• We are going to OSINT

Once we’ve built out payloads up, we are then going to start sending requests, we need to consider a few things here.

• Is there a WAF/IPS?
• Is there a lockout policy?
• If an account gets locked, does it automatically unlock? If so after how long?
• Do source IPs get banned?
• If we get banned how long are we banned for?
• Do I need to use a rotating proxy?
• Do I need to use pwn3d infra to hide my tacks?
• Can I attack using services like TOR to hide my tracks?
• Is there a security team at the organisation who are going to try and stop me or even pursue me?
• Are they monitoring logs?

Wow there’s a lot of things I need to think about as an attacker!

Example – Defending SSH

Ok so let’s create a quick list of things we can do to defend an exposed SSH service!

• Configure account lockout policies
  • Group Policy for Windows, pam.d for linux)
• Conduct regular password audits
• Train people on good password practises
• Deploy fail2ban or similar service (unix/linux)
• Use web application firewalls (if appropriate)
• Monitor audit logs
• Deploy password managers
• Use 2FA/MFA
• Only change passwords if there is a reason to, forcing regular password changes makes people create weak passwords
• Ideally look at attack surface reduction, if an interface doesn’t need wide exposure keep it somewhere less open to attack (ACLs, VPns etc. are great for this)
• Use conditional access solutions
• Consider limiting where high privildge accounts can be used (use the PAWS luke!)

There’s a ton of things that can be done to make your network safer!

Summary

Weak authentication controls, lack of monitoring etc. are just some of the weaknesses that affect organisations on a daily basis. Exposed services on the internet will be being hammered by threat actors round the clock (we know they are because we have honeypots) so ensuring you have foundations solid is key, even if that’s whilst you buy time to go and look at implementing more advanced controls such as just in time access, hiding services behind vpns etc.

The key thing is to understand your networks, understand your identity systems, authentication systems, attack surface and the threats you face so that you can defend against the pwns! Hopefully this blog has got you thinking about things that whilst are basic/foundational, still get organisations into cyber hot water (oh come on I couldn’t resist!)! be safe, secure all the things, until next time!