How should you prepare for an infrastructure pentest?
Here are 5 steps you can take right now to improve your cybersecurity, prepare for your next pentest, and make those pentesters work much harder.
This guide breaks down these 5 topics, helping you prepare for your next penetration test. It also provides a handy reference so you can ensure these issues are kept under control between tests.
Fixing these issues will significantly improve the security of your environment, and make your penetration testing team work much harder!
The 5 common issues
Spoiler alert! These are the topics we’re going to cover in this blog post. What they are, how to spot them, and how to fix them.
-
Default credentials
-
Network attacks
-
SMB Signing
-
Scheduled tasks
-
File shares and Sharepoint
Why get a penetration test?
A penetration test provides a deep dive into the security of your IT environment, showing you what an attacker could achieve. The aim is not to scare, but to provide simple and clear steps to improve security and reduce the impact of a cyber attack.
Recently, penetration testing and vulnerability scanning have become confused. A penetration test is not focused on the version of Adobe acrobat running on someones laptop, but on exploitable real-world issues.
A good penetration test should use expert testers who are able to tease out those unusual conditions which allow an attacker to cause devastating damage.
Default credentials
We’re starting off with the easiest attack to understand, but one which is still a huge problem across organisations. On nearly every test we’ll see default credentials for applications and devices.
Some modern devices have secure defaults, such as a unique password printed on a label attached to the device. Unfortunately most do not. The risk posed by each application or device varies, but can lead to full IT compromise.
On a recent penetration test, we found a backup service running with default credentials. A quick search on the internet found the default username was admin, and the password was admin. We tried them and we were straight in!
This backup service allowed you to create scripts that ran before and after a backup job, so we created a script to add a new user to the server. We ran the backup job, created the user, and signed right in.
This backup application had been installed for over a decade!
ACTION POINT: Find and remove default credentials
Fortunately this isn’t a difficult problem to solve. You need to identify as many services in your IT environment as you can, and then set strong passwords if they are default. We suggest the following easy steps:
Change all the passwords you know are default
Look through your password managers (or password spreadsheets!) looking for any obviously default passwords
For your critical equipment (like CCTV, UPS, etc) open their web management pages and try the passwords from their quick start guides. you can find these on the internet really easily.
Run discovery scanners to find all the management interfaces you didn’t know even existed. You want to focus on devices with ports 20 and 21 (FTP), 22 (SSH), 23 (TELNET) 80 and 443 (HTTP). If you find a service, identify it and try and log in.
Want more technical advice on identifying and attacking this? We’ll have a follow up blog soon!
Another common but critical scenario to look out for is highly privileged credentials in IT scanners, such as monitoring and vulnerability scanning tools. If these tools have default passwords, attackers can weaponise those administrative credentials to gain admin access across your IT environment.
Sometimes systems don’t give us anything nearly as exciting, but which can still be used. Printers are a great example. We find a lot of Microsoft365 usernames and passwords configured on printers to allow them to send emails, and often these are excluded from MFA requirements too!
Network attacks
Network attacks give us the opportunity to steal users passwords, or access systems as the user. We do this by inserting ourselves between the victim and the service we want to attack. There are a few techniques for doing this, but the aim is always the same.
The techniques we will typically use for network attacks are NetBIOS poisoning, mDNS poisoning, LLMNR poisoning, and ARP spoofing. There are a few more attacks techniques, but we don’t typically use them during testing because they can be very disruptive …and we don’t typically need to!
Poisoning attacks are interesting, and they attack the same quirk in computer behaviour.
If you mistype a website address (for example you try and go to punksecurity.co.ukkkkkk instead of .uk), what happens? Well your computer will ask its DNS Server to turn the address into an IP address. It needs this to connect. If that fails, it will start to ask other computers on your network if they know the answer.
When we’re doing a poisoning attack, we just wait for these requests, and answer “Yes, that’s me!”.
Most of these type of network attacks need the attacker and the victim to be on the same subnet. So if the attacker is sat on your user network, they cannot perform these attacks against servers.
During all of our pentests, we ask to put multiple devices near your users. This allows us to test network attacks much better. You’ll discuss this with your penetration tester a few weeks prior to the start of your test
ACTION POINT: Prevent network attacks
Different network attacks require different protections. Some are applied by policies, and some via network configuration. Here is our round-up of fixes you need to apply:
Prevent NetBIOS poisoning: This is typically done via DHCP, with a setting on the DHCP server. If that’s Windows, try this article
Prevent mDNS and LLMNR poisoning: This is configured via Group Policy, check out this guide here
Prevent ARP spoofing: This depends on the your network switches. Look out for the Dynamic Arp Inspection feature.
Segment your networks: Network attacks typically work only in the same subnet, so separate networks into multiple subnets to limit the scope of an attack.
Want more technical advice on identifying and attacking this? We’ll have a follow up blog soon!
SMB Signing
This is a complex topic, with an easy fix!
SMB is the protocol used for Windows file sharing, and SMB Signing prevents an attacker from being able to get in the middle of the conversation and send it somewhere else.
Why is this important? Well, when we perform a network attack against a victim they try and connect to us. They will try and authenticate to us, but they don’t give us their password directly (well, most of the time). So we have something called a password hash, which we need to crack. An easy password hash will crack and we’ll get the victims password, but a strong password wont.
BUT, if we can forward the connection on to a server without SMB Signing enforced… Well, then we don’t ever need to try and crack the password. If the user can read/write any files, then we will be able to as well. If they’re an administrator, we can run commands.
ACTION POINT: Enforce SMB Signing
This is a really easy fix, just enforce SMB Signing via the registry or Group Policy:
Enforce SMB Signing via Group Policy
Relax
Want more technical advice on identifying and attacking this? We’ll have a follow up blog soon!
Scheduled Tasks
It is rare in penetration testing to go from nothing to full compromise. Quite often we have a users password, or a limited window of access. So we need to find ways to move to other servers (lateral movement), or get more permissions (elevation). A great way to do this is via misconfigured scheduled tasks.
The general concept is that we want to find a Scheduled task that runs as a user which would be interesting to us, and we need to be able to modify what the task does. Quite often the task will run a script, which we might be able to edit, or will run an executable we can replace.
This issue also applies to services, where the binary the service runs can be modified. This is a little more complex to attack though as you’ll need to build a custom executable.
Here are our 2 scenarios of interest:
Scenario 1: User to administrator
A scheduled task runs as SYSTEM (which is full system administrator) but runs a script or executable we can modify or replace. In the case of a script, we add some commands to add a new admin user and then simply log in with it after the task next runs.
Scenario 2: Administrator to Domain administrator
A scheduled task runs as a Domain Administrator, or some other domain user which is of interest to us. As an administrator on the system, we can always replace the scripts and executables the task runs. This means if we get administrative control of a server with a scheduled task running as Domain Adminstrator, we will always be able to get full control of the domain.
ACTION POINT: Clean up scheduled tasks
This one takes a little bit of detective work. Large organisations could use powershell remoting to reduce effort.
Check every server (and a sample of user devices) for Scheduled tasks. There will be some built in tasks, and these can be left alone. You are looking for anything custom or unusual, running as
SYSTEMor specific user account.When you find a task running as a domain user, check what permissions that user has. Can they do risky things?
If you find a task running as a domain administrator, CHANGE IT. This configuration is almost always a shortcut and should never occur.
If the task runs as
SYSTEM, check what it runs. Make sure this file can only be edited by administrators, and not any other user on the system. Definitely remove any permissions forauthenticated users,users, oreveryone.Want more technical advice on identifying and attacking this? We’ll have a follow up blog soon!
File shares and Sharepoint
Our final tip is simple to understand but hard to fix.
File shares and Sharepoint sites (and sometimes IT knowledgebases) are not good places to store passwords.
A good amount of penetration testing is spent going through these locations looking for passwords that can be used. Sometimes we get on a file share using an SMB Signing attack, or sometimes we get access to a file share with no username and password at all!
On one recent penetration test, we managed to get Sharepoint access via the user configured on a printer. Within a few hours, we’d collected enough credentials from Teams call recordings to compromise the entire environment
ACTION POINT: Housekeep!
It’s time to do some housekeeping. SMBeagle can help!
Give yourself a standard user account and then see what files you can access on shares. You may be very surprised at what you can access! We have a tool for this, check out SMBeagle.
Review IT file shares, sharepoint sites, and knowledge bases. Get those credentials out of there and safe.
Review and delete old accounts. It doesn’t matter if a script contains an administrator password, if the administrator account has been deleted!
Want more technical advice on identifying and attacking this? We’ll have a follow up blog soon!
In summary
Sometimes one of these issues is enough for an attacker to completely take over and destroy an entire IT network. Default credentials can be devastating, but so can SMB Signing not being enforced. If you leave a password in a script that anyone can access, then it doesn’t really matter what other protection you have!
But what about EDR?
Modern anti-virus and threat detection is powerful, but won’t detect or block any of these techniques. Unfortunately it’s just attackers using systems the way they were intended to be used. You may detect and prevent ransomware, but your data is likely already stolen anyway.
Fixing these issues will significantly improve the security of your environment, and make your penetration testing team work much harder!
None of these action points require complex skills to fix, and can all be easily fixed whilst you’re waiting for your next penetration test to start.
Punk Security provide Infrastructure, Web, and Physical penetration testing alongside our expert DevSecOps consultancy services.
