Pentester’s Note: Hunting Cases – 2
We continue the conversation for interesting cases in the work of pentesters. In the last post, we talked about external penetration testing, today we’ll talk about the most interesting internal pentest tests that we have implemented recently. Their essence is that we should, being in the internal perimeter of the customer, receive the maximum privileges in the domain and get to any important data. It happened to be surprised. But first things first.
Case 1. Password manager is good, but they need to be able to use
We conducted internal penetration testing for a large client who already had trained sysadmins and an IS service. In the course of the work, we received several accounts with which we were already able to go on the network and connect to the machines of other users. At some point, they settled in the car of one of the system administrators and found an eldorado there. The system administrator used really complex passwords (it would be difficult to find such ones) and even stored them in keepass’e. But here's the bad luck: the password manager itself was never blocked – not after 15 minutes, or at the time the screen was locked. With this bonus, we got administrative rights in critical customer systems without noise and dust.
Another client had a similar case. Also complex passwords, also keepass, though there still was an auto-lock after 15 minutes. How could we use this? They waited until the administrator locked the desktop and left (for lunch?). Then it was a small matter.
If you use password managers, use them wisely – turn on the lock option with a lock screen’s and in the absence of activity for 1–5 minutes.
Case 2. Dismissed employees
Very often, during internal pentests, we gain access by selecting passwords – users are usually too lazy to come up with complex combinations, especially when the password policy requires updating them every month. Often the numbers simply change – so, superpassword_03.2019 a month later turns into superpassword_04.2019 and further down the list.
But sometimes customers come across quite out of the blue. So, conducting a password spraying attack in one of the companies, we got a number of accounts and one of them was especially interesting to us: she had fairly broad rights, although not admin rights. An easy password was set for her (qaz12345), and the comments on this entry in AD indicated that the employee was fired – judging by the date, almost a year ago. That is, after the dismissal, the account was not blocked, but simply reset the password to “default” and set the option “change password at the first login”. For the happiness of the customer, we were the first who were invited to do this.
Case 3. Patches? Nah, don't
The most difficult part of the internal pentest is getting the first account. There are many tools and ways to do this, starting with an espionage fashion show in the office looking for cherished stickers with passwords and catching the afflicted with a cloned office Wi-Fi, ending with attacks on Kerberos and password cracking of accounts. But sometimes, even with the initial scan, you can find software that no one has been updating for ten thousand years (why bother updating software in the internal infrastructure?).
In one such project, they came across the management software from HP, in which RCE was found without authentication – from it they got part of the accounts.
¯ _ (ツ) _ / ¯
It seemed that everything would be simple further – Mimikatz, and the thing is in the hat, but it turned out that the accounts received did not possess the privileges we needed. As they say, our strength is in readiness for the cloud: using nmap’a magic and the smb-enum-shares script, we found out that one of the accounts had local admin rights on the test server, which domain administrators were actively involved in at that moment =).
Case 4. Locks
Finally, let's talk a little about possible access blocking. Work on the "vnutryanka" we carry out most often with remote access. The scheme looks like this: we connect to the VPN, we get the internal address, then we cling to the machine allocated for us via RDP. And with this machine we are already starting to work, but for this we need to somehow convey our tools. Many of our clients use proxy servers with white lists of sites, sometimes even with white lists of ports, to get Internet access (for example, you can connect to a website with port 80, but you can no longer connect to 8081). It really makes work a little more difficult, especially if copy-paste is prohibited through RDP.
But where in our business without nuances. One client had very strict rules and we were not allowed to fill our tools in an official way, so to speak they prevented penetration through the “main entrance”. Like, here’s a virtual machine and minimal rights for you – suffer like real hackers.
I did not have to suffer for long. The proxy really blocked a lot, it was not even possible to simply connect to its http server (it is not in the white lists), copy-paste was prohibited, the browser refused to go anywhere except http (80 / tcp) and https (443 / tcp), and somewhere other than internal portals. We tried wget through powershell – it also does not work, it does not go without a proxy, and the proxy prohibits it. But the built-in FTP utility of Windows worked fine – there were no rules on the firewall that would block such traffic. So we dragged all our tools inside the perimeter and were able to do a great job.
In the end
I will repeat the recommendations from the previous part, because the repetition is the mother stuttering teachings. Carry out periodic penetration testing – they will help you find delicate spots in your defense, as, for example, in case 3. You may consider that it is not necessary to patch systems in the internal perimeter, but sometimes it leads to grave consequences.
Build a patch management system – eliminate not only “high-profile” vulnerabilities (such as EternalBlue or BlueKeep), but also less well-known, but no less dangerous if used (as is the case with HP AM). In short, keep track of all your systems.
