Signpost in a park with arrows pointing two opposite directions towards Entrance and Exit. Image is overlaid with Nexon logo and a yellow diagonal shape.

Last year, our Penetration Testing team completed over 100+ engagements across clients from all industries and from all sizes.  These organisations ranged from a small 3-person accounting firm to a large multi-billion-dollar global retailer (spanning tens of thousands of users), and everything in between.  In this post I want to share some common observations from these engagements and the most common weak points we have observed.

My goal?  To give you some focus areas for your organisation to act on immediately.


7 Key Weak Points

Here are the 7 key weak points that we observed in most of our engagements.  For each weak point, I’ll give you context and mitigation actions that you can take right now.  Feel free to skip to the section that is of most interest to you by using the links below.

  1. Password Sprays
  2. MFA – Multi-Factor Authentication
  3. Phishing & Social Engineering
  4. Passwords
  5. Network & Account Hygiene
  6. Detection & Response
  7. Webapps


Password Sprays

Across a very large number of engagements last year password sprays were an easy win for our team when it came to obtaining an entry point.  Password Sprays are nothing new, they have been our number 1 into the environments we are testing, alongside phishing, for several years now.

What is a password spray?

If you are new to password sprays, it is when an attacker tries one password against all your accounts, basically on the premise that at least one or more of your accounts is using a common password.

First, the attacker harvests a list of usernames and/or email addresses via reconnaissance of publicly accessible information. Then, they methodically go through a list of potential passwords, spacing their attacks out to avoid lockouts.

Let’s say the attacker’s first try is Password1.  Using Password1 to try and gain access to all the accounts, this is called a spray.  The attacker then waits for a period to avoid lockout before they try the next one.  Once that time is up, they then spray with Password2, wait a bit, spray with Password3, and the cycle continues, going through their password list.

With traditional brute force attacks there is a higher risk of locking out accounts, and detection is much higher.  However, password sprays get past this and often avoid detection, especially when it comes to services that are using on-premise authentication.

Our findings

Its positive to find that many organisations adopt Azure Smart Lockout, which limits our attacks but does not stop them completely.  Often, we can have between 5 and 10 sprays before Azure picks up something isn’t right.  In a lot of cases that’s all we need to gain access to at least some user accounts.

The more external services you have facing the internet, the more potential options for spraying.  Services that yield us good results with spraying include:

  • Outlook Web Access
  • Microsoft Online (Azure/365)
  • Active Directory Federation Services (ADFS)
  • Firewall Web Services / VPN Portals (In my opinion, the firewall offering the best password spray protection out of the box is Fortinet.)
  • Other Web services (extranets, HR Portals, custom webapps etc)

If you are utilising any of these services, you should review and decommission where possible or apply additional protections such as Azure Smart Lockout, Conditional Access, ADFS Extranet Smart Lockout etc, as well as ensuring you are detecting (and responding to) these attacks.  Microsoft have a totally awesome reference here on detecting and responding to password sprays.


Mitigation Actions

  • MFA – on everything, and for every user.
  • ADFS – implement Extranet Smart Lockout.
  • Azure – configure Azure Smart Lockout (Identity Protection), and policies like Conditional Access.
  • Passwords – enforce passwords on users aligning with Microsoft and NIST best practices (more on this to come), configure lockout thresholds, and enforce a banned password list.
  • Disable legacy authentication protocols like POP and IMAP etc. that do not support MFA.
  • Detect it! Ensure your organisation is logging to a SIEM (Security Information & Event Management) tool, or another solution that gives you visibility and allows you to respond quickly & effectively.
  • Adhere to the concept of zero trust: trust nothing, verify everything.



Another quick win, missing Multi-Factor Authentication.  These days we normally find MFA is enabled on most client engagements (especially on 365/Azure services).  However, we almost always find that some accounts are not MFA-enabled.  We also often find accounts that have MFA enabled but it’s not configured, or simply not applied at all.

Another common finding is organisations that are “Partial MFA”, meaning they have some services (or most) configured with MFA, but some or maybe even a single service that is not, for example, VPN services.

So, what is my team going to go after when we are Penetration Testing?  The path of least resistance.  This means the non-MFA configured service first, OR, we might spray against M365 first, find validated credentials, then go and reuse those credentials on the non-MFA-enabled service.  (This is called Credential Stuffing.)

MFA Education is Key

With widespread adoption of MFA, other related challenges have arisen that we see organisations facing, but most of all, a lack of MFA education is probably the one that creates the most havoc.

Let’s use Microsoft 365 as an example. It is one of, if not the most common suite of business software in use globally, as was the case for most of our engagements.

If an organisation has Microsoft 365 and MFA is in place, our team will wait until staff members are typically starting work for the day before we first attempt to login.  When we do, the user is sent an MFA prompt, and often, because they are so used to receiving prompts, they just choose “Accept.”  This is especially true at this time of day because of several factors: they might be rushed, or they might have a meeting coming up; they might have multiple apps booting up, so they’re expecting the prompts; they might be distracted with getting their day organised, etc.

This works really well if the user has push notifications turned on in the MFA Authenticator app and is not using input code.  Most users will blindly accept our MFA prompts, and if they don’t, we will then try at other periods during the day.  Or, another tactic is to flood them with a bunch of MFA prompts, and usually the user will just hit “Accept” to make the message go away.

Using code input rather than push notifications works well with stopping us here, but at the end of the day, your users need to be trained to not just accept any old MFA prompt.  This is especially important when your staff are hybrid working from home, or perhaps they are using BYOD (Bring Your Own Device), where they may get prompts on their own devices because they are not company/domain joined.


Mitigation Actions

  • Enable MFA – this is a quick win for you. Make it enabled on every service and apply to every single account except an emergency “break glass” admin account.
  • Disable SMS and Push Notifications for MFA – require your users to type in a code.
  • Education – run an internal campaign to your staff about not blindly accepting MFA requests.
  • Run a report – understand who your MFA- and Non-MFA-enabled users are.
    • You can use this script.
      • To get 365 users without MFA, run it like so: ./GetMFAStatus.ps1 -DisabledOnly
      • For admins without MFA, add in the AdminOnly switch: ./GetMFAStatus.ps1 -AdminOnly -DisabledOnly
    • Enable MFA from your internal network as well – we often find organisations have MFA enabled for external access, but once on the internal network (or stemming from trusted IP addresses) the MFA requirement is turned off. This means that once we breach another service like the wireless or VPN, we have access to everything in M365.



Phishing & Social Engineering

Yes, phishing, spear phishing, & social engineering are as prevalent and as successful as ever.  Phishing and social engineering still, almost every time, provide us some degree of access into a client’s environments and/or accounts.

Old technique, but it works

To paint a picture, we created around about 110 custom phishing & credential harvesting campaigns last year.  Of those 110+ campaigns, only FIVE did not yield any credentials.  That’s a 95% success rate, which, let’s be honest, is not great.

When it comes to phishing, users these days are much savvier than in the past, which is great!  But we still yield a large degree of success with phishing & credential harvesting campaigns, and other similarly styled attacks such as Vishing (Voice & Phishing).

As I mentioned before regarding MFA, the same applies here when it comes to education.  Users need to be made aware, and they need to adopt the zero-trust model themselves: trust nothing, verify everything, and if in doubt – contact IT!


Mitigation Actions

  • Buy up similar domains – this is something that we addressed in a blog post last month about the new .au TLD release.  You would be surprised how often we can buy a similar domain to an organisation’s legitimate domain, such as, .biz, .org, etc.  Throw on a company logo from Google, and sadly, it is almost immediately trusted by the end users.
  • Educate your users on phishing and social engineering – we find that micro-learning programs work best.
  • Periodically phish your staff – yes, I’m serious – this is like a fire drill. Phish them every month to keep them on their toes!
  • Standard technical controls should be configured from a system side by IT: DKIM, DMARC, SPF, email filtering, Impersonation Protection in 365, MFA, detection systems, etc.




Year-on-year passwords (especially combined with sprays) yield us entry points into some of the most secure environments.  I know, passwords are the bane of everyone’s existence (maybe time to go passwordless with Windows Hello & FIDO? 😊), but passwords are still an area both IT and end users do not understand.  The recent changes to best practices from NIST and Microsoft have left most organisations confused when it comes to passwords.  So, I’m going to break it down for you.


If your organisation IS NOT full cloud

If you have some systems in the cloud, and some systems still local/on-premise – irrespective of the share of each, then this is for you:

  • Password Complexity Requirements: not needed
  • Password Length to enforce: 12-15
  • Password Expiry: 3-6 months (depending on organisational operating requirements)
  • Lockout Requirements: 3-5 attempts (depending on organisational operating requirements)
  • Configured Banned Password List: absolutely


If your organisation IS full cloud

First of all, well done, you are infinitely more secure!  On-premise infrastructure is inherently less secure, and by being fully in the cloud, you’ve removed one factor from the mix.

If you are using all AAD-joined machines, SaaS, and IaaS and/or cloud services, lucky you, it’s time to relax your requirements:

  • Password Complexity Requirements: not needed
  • Password Length to enforce: 12-15
  • Password Expiry: never
  • Lockout Requirements: 10+ attempts (365 default) but make sure you enable Smart Lockout
  • Configured Banned Password List: absolutely


“12-15 characters and a banned password list?  There is no way our organisation will go for that.”  I’m sorry, but that’s complete crap.

Tell everyone in the organisation to pick 4 words that mean something to them, for example: “my dog is black”.

BOOM!  There’s your password.  It’s 15 characters, impossible for an attacker to crack/guess and dead simple for people to remember.

Again, education is key.  You should be educating your users to:

  • use spaces in passwords
  • use sentences or passphrases
  • not worry about complexity – with complexity we know that users will just rotate numbers and use a common syntax, like Password1, Password2, etc.


Mitigation Actions

  • Change your password policies to align with the above.
  • Do not reuse passwords across user and service accounts.
  • Regularly change service and admin account passwords.
  • Segment admin from everyday accounts.
  • Implement a banned password list, for example company name, products, etc.
  • Do not store your passwords in mailboxes and shares, use a password manager.
  • Educate your users on password creation, usage, not re-using, and storage of passwords.



Network & Account Hygiene (or lack thereof)

This particular issue is common across nearly every assessment we perform, and a lot of the time, leads to domain admin access for the tester.  IT staff are busy, often under-resourced, and as a result, network and account hygiene is often pushed to the back of the queue.  This allows a whole range of potential risks, from access to unauthorised data by a malicious insider or contractor, through to denial-of-service conditions and compromise of the entire network.

Your IT team should carve out time each week or fortnight to perform periodic housekeeping on your environment.  This should include:

  • Removing default and blank credential configuration within the environment, including default community strings.
  • Searching for any suspect/rogue devices on the internal network – run a netscan, Nmap, advanced IP scanner, etc.
  • Deploying regular OS, Windows, Apps, & Hypervisor updates/upgrades.
  • Removing blank or open services on the internal network, like FTP, Telnet, and SMB Null access.
  • Disabling insecure services such as Telnet, FTP, SMTP, IMAP, etc and/or replacing them with secure alternatives.
  • Disabling services like SMBv1 and LLMNR.
  • Doing a search on the network shares for sensitive data such as credentials. It’s as simple as doing a search for basic terms such as pass, login, credentials, etc.
  • Performing a periodic review and clean-up of accounts and group memberships locally and within 365.
  • Performing a periodic review and clean-up of admin group membership within the local network, and global admin and elevated access within 365.



Detection & Response

Arguably one of the most important focus points for any organisation is their detection and response capabilities.  How can an organisation respond to a security event if they don’t know that it is even happening?

We find this is very common across nearly all engagements, and often, we have completed our breach phase before any alerting/potential detection is received from IT.  When a breach happens, seconds and minutes matter so being able to respond to a cyber-attack quickly and effectively is paramount.  It goes without saying, but I’ll say it anyway: the more data you can capture, the greater your visibility.


Mitigation Actions

To ensure you are in a position to respond effectively, ensure you:

  • Have an incident response plan, and it is tested annually.
  • Implement a SIEM (Security Information & Event Management) solution. Start with basic log management and expand from there.  There are lots of free and paid options for SIEM solutions, like Elastic/Kibana, Sentinel, LogRhythm, etc, but the more data you can send to the SIEM tool, the more effective it will be.  (Bear in mind that more data could result in a potentially higher ingestion cost.)
  • Utilise a SOC (Security Operations Centre) service to provide overwatch and triage. We see this a lot: IT teams simply don’t have the resources and often, not the skills, to triage security alerts. By outsourcing your SOC, coupled with a SIEM solution, your environment can be well and truly covered.
  • Educate your users on cyber risks and the importance of notifying IT of events or “strange things”.
  • Have visibility and alerting on for 365/Azure for:
    • Changes to tenancy or Azure admin rights
    • Group membership changes
    • Role changes
    • M365 illicit consent grants
    • Standard 365 security alerts, impossible travel/risky sign-ins
    • Mailbox forwarding rules setup for external
    • Inbound forwarding rules setup
    • Creation of accounts within tenancy
    • Creations of Teams, as well as Channels and other resources
    • Non-owner mailbox activity
    • Failed sign-in attempts
    • Azure resource and/or app creation
    • Changes to applications, such as application role assignments
    • Sharing and access request activities (such as users creating links that enable external people to access remotely).
  • Have visibility and alerting on for internal threats. (We’ll be publishing a post soon on preventing insider threats that will include the various internal alerts to capture and alert on, so stay tuned for that!)




Webapps are probably the most complex of all areas outlined this blog post; both to discuss and to remediate issues.  From a mitigation perspective, many of the weaknesses that I’ll point out below can be rectified by doing the opposite of what we’ve observed; for example, turning something on that was previously off.  However, in many cases, that’s easier said than done, depending on the application.  As always, if anything raises any questions, let me know.

Across our engagements last year, these are the biggest and most common vulnerabilities we identified in webapps based on the OWASP Top 10 categories.


Broken Access Control (OWASP A01:2021)

Access control is all about restricting users from performing actions outside of their intended permission. Access control is broken when such restrictions are not implemented correctly. This allows unauthorized access to, modification of, or destruction of, sensitive information.

Vulnerabilities we often observed associated with access control include:

  • Evasion of access control checks – by changing parameters or strings or modifying HTML or URLs.
  • API endpoints/requests – having limited access control, or in some cases, NO access control.
  • Insecure Direct Object Reference (IDOR) – this vulnerability allows users to access objects or admin functions outside their current permissions.
  • Directory traversal vulnerabilities – allowing directory enumeration and therefore access to privileged pages that may contain sensitive information.
  • CORS based vulnerabilities and untrusted source access to API’s.
  • Missing Multi-Factor Authentication (MFA).


Cryptographic Failures (OWASP A02:2021)

A lack of cryptography applied to data (or a vulnerability within the cryptography) is known as cryptographic failure in the OWASP categorisation world. This applies to both ‘data at rest’ and ‘data in transit,’ and different levels of security may be needed, depending on the nature of the data.  This is especially key when the data includes authentication details such as usernames and passwords, as well as personally identifiable information (PII).

Man-in-the-middle (MitM) attacks are often leveraged to exploit vulnerabilities in this category.  The most common issues we see when it comes to cryptographic failures:

  • Use of HTTP instead of HTTPS for storing or transmitting sensitive information.
  • Use of weak SSL algorithms (ciphers) and protocols.
  • Missing strict transport security headers (HSTS).
  • A lack of encryption enforcement.
  • Certificate validation/certificate issues.



Injection (OWASP A03:2021)

An injection attack is when untrusted data is entered into the application, forcing it to execute code that was not intended. Several injection attacks are possible, including SQL injection and cross-site scripting (XSS) attacks.

The most common issues we see:

  • Database error messages and strings (SQL injection isn’t as prolific as it once was).
  • Cross-Site Scripting (XSS) – mainly reflected, but we see stored as well.
  • Validation, filtering/sanitisation of input and input data is either lacking or non-existent.


Insecure Design (OWASP A04:2021)

Software development can have design flaws which result in logic vulnerabilities.  This issue is mainly addressed during the SDLC (Software Development Life Cycle), but failure to incorporate secure design can lead to us identifying and exploiting any of the other OWASP category vulnerabilities.

Mitigation Actions

Software Developers should ensure that they are:

  • Identifying, assessing, and integrating security and privacy concerns into the design lifecycle (SDLC)
  • Using secure coding techniques and using tools to perform SCA (Secure Code Analysis) prior to go-live.
  • Using a list of ready-to-use or reusable components or a library of secure design patterns.
  • Using the latest version of all incorporated libraries and technologies and utilising SRI (Sub Resource Integrity) where possible.
  • Perform user authentication and access role testing to determine if users can move outside their assigned functions and exploit logic flaws to perform functions or access areas they shouldn’t.
  • Get a pentest done on any new apps prior to go-live. (And I’m not just saying that because that’s what we do – but you really should.)


Security Misconfiguration (OWASP A05:2021)

Security misconfiguration can be defined as having security controls that are not configured correctly, or that are inherently not secured by design.  Some of the common issues we see in this category include:

  • Web/application servers not fortified with hardening – this is really common with shared web hosting.
  • Unnecessary services, ports, and pages exposed, such as admin interfaces, and usage of legacy services like POP3, IMAP, SMTP, etc.
  • Directory listing vulnerabilities – relating A01:2021 above.
  • Sensitive information presented in error messages to users and via TRACK/TRACE responses, as well as banner and underlying host information leakage.
  • Missing secure headers or directives, like Content-Security-Policy, Script-Src, etc.
  • Legacy versions of frameworks and libraries in use – we showcased one on our blog earlier this year with Log4j, and legacy JQuery is also a common occurrence.
  • Missing security updates.
  • Lack of – or insufficient – WAF (Web Application Firewall) protection.


Vulnerable and Outdated Components (OWASP A06:2021)

This one is quite simple, but often leads to us compromising the application and/or underlying host.  Issues we commonly see:

  • Outdated or unsupported web server or technology usage.
  • Outdated libraries, servers, and databases and database management systems.


Identification and Authentication Failures (OWASP A07:2021)

This OWASP category is all about authentication-related attacks and ensuring the user’s identity, authentication, and session management is protected.  We find vulnerabilities in nearly every web application assessment relating to this category.

Common vulnerabilities we find:

  • Application is vulnerable to attacks like credential stuffing.
  • Brute forcing of credentials or data with no rate limiting applied on applications and APIs, such as PINs, password reset forms, login forms.
  • Applications not using different response codes for valid and invalid users/requests.
  • Lack of MFA usage.
  • Lack of monitoring, alerting, and blocking for brute force attacks.
  • Weak password controls.
  • Transmitting of sensitive data (such as credentials) in clear text or insecurely.
  • Session tokens in URLs containing sensitive information.
  • Replay vulnerabilities associated with tokens and session IDs.


Software and Data Integrity Failures (OWASP A08:2021)

This category related to software updates, critical data, and CI/CD pipelines without verifying the integrity of the files/code updates.

The vulnerabilities we normally see in this category:

  • Misconfigured repositories and access.
  • Missing Sub Resource Integrity (SRI) protection.
  • Weak encoding (such as Base 64 usage).
  • Using software or integrating with 3rd party software/libraries that contain vulnerabilities or are running legacy versions.


Security Logging and Monitoring Failures (OWASP A09:2021)

Similar to the detection and response section above, this component is all about ensuring you have logging/visibility when it comes to attacks and breaches.  Like network environments, this is an area lacking when it comes to most web applications.  The most common issues we see:

  • No alerting when dynamic testing tools (DAST) are being run against the site.
  • No alerting/visibility when brute force or other attacks are underway.
  • No logging of application and API traffic in order to monitor for suspect activity.
  • No real-time visibility around attacks, for example, no WAF.


Server-Side Request Forgery (SSRF) (OWASP A10:2021)

SSRF flaws occur whenever a web application is fetching a remote resource without validating the user-supplied URL.  This allows attackers to make the application request resources from an unintended location.  For this last category, the issues we normally see:

  • Bypassing of input filters.
  • Lack of whitelisting and expected response handling.
  • Blind SSRF vulnerabilities.
  • Back-end SSRF vulnerabilities.
  • Default services without SSRF verification.


Food for thought

I hope this blog post has given you some food for thought on areas that may be lacking within your digital estate and current processes that may expose you to a breach or security event.  If any of these points have raised any questions for you, please, reach out to me on LinkedIn, I’m happy to discuss them further.


If this article has made it clear to you that you would like an in-depth assessment by highly experienced penetration testers, please reach out to us – we would love to hear from you!