*Identifying details have been changed to protect the innocent and the haunting hacker spirits who wished to remain anonymous.
Happy Halloween (and end of National Cybersecurity Month) everyone!
As TRUE’s (self-proclaimed) Halloween and Horror Movie expert – seriously, read my LinkedIn profile sometimes – and one of the resident Security Consultants (read: professional hacker), I know scary. Like, really scary. No, not just horror movies/books/art/posters/80’s VHS covers/etc., but stuff that is REALLY SCARY.
My Side Desk - I collect Horror Movie collectibles, mostly Friday the 13th gear, as well as spores, mold, and fungus.
Like ways to break your external network, bypass your defenses, and get your data. Financial records, proprietary information about your latest prototypes, medical or student records, stuff like that.
You know, that data that no one who is not an employee should ever have access to…and this includes some of your employees?
So, in the immortal words of Dan Ackroyd:
Wanna see something really scary?
A year or so ago, we were given a client to perform a full scope Red Team engagement on. For those unfamiliar with the term “full scope Red Team engagement”, it was essentially a penetration test of the external and internal network (including wireless), complete with phishing and vishing (email and phone-based social engineering, respectively). The rules of engagement were – basically – don’t perform a denial of service on anything. No problem.
Let’s do some recon!
The client was pretty solid overall on the external network – not a lot of services open to the internet, mostly HTTPS, a couple of SSH servers, a couple of Citrix servers, a VPN server, an Outlook Web Access (OWA) server, and a Skype for Business (S4B) installation.
And TCP ports 135/139/445 – Windows SMB. What? Why is this here? Shouldn’t this be firewalled off?
Anyway, after doing some online research (Open Source Intelligence – OSINT), I was able to secure a couple of usernames to test against the server, but what was interesting is that the usernames were not the same as the email addresses I had discovered, and this threw a bit of a monkey wrench into my attacks. Which was good, but overall, something I could (with some time) workaround. I discovered the usernames in different PDF documents hosted on the client’s website, as well as some Office documents they had hosted as well. One username I had actually found in an email on a mailing list that had not been scrubbed. No passwords anywhere, but that wasn’t a huge deal. I would get those eventually. The usernames were essentially three letters followed by five digits, except, from what I could tell, the letters weren’t really random. All the usernames I found started with JS, and then had either an A or B as the third letter, followed by the five digits. The five digits were random, but that was EASY to script.
Since I had access to the OWA, the Skype for Business suite, and the Citrix servers – all were tied back to Microsoft Active Directory (AD) – I figured I could use the usernames I had found as the template for creating new usernames, and then use a password spray technique (testing multiple *usernames* for a *single* password – think password brute-forcing but in reverse) on any one of the open AD-tied services. As it turned out, Skype for Business was vulnerable to the LyncSmash attack (thanks Black Hills InfoSec!), and I could enumerate good usernames to use in further Breaking and Entering efforts. Of course, I did this by using Python (not Ruby! Ha!) to generate a list of usernames with the correct syntax for testing purposes.
About LyncSmash
Skype for Business (S4B, for short) was formerly known as Microsoft Lync. It was Microsoft’s communication platform for businesses, until they rolled it into the Skype platform (which is now – or so I’ve heard – being rolled into Microsoft Teams). LyncSmash is an attack designed to take advantage of the fact that on the S4B web application, AD authentication has a timing condition which can be tested for valid and invalid usernames. When tested with an invalid password, the authentication will either come back in a split second for valid usernames, or a few seconds for invalid usernames. LyncSmash tests this by creating a randomly generated password and throwing that password at several different usernames to see how quickly the authentication is rejected. If the rejection is quick, then the username is valid, and if it takes a bit, the username is most likely invalid. LyncSmash also does other stuff, like finding legitimate usernames with legitimate passwords for breaking in as well, which we’ll see in a few.
Back to the show…
After using LyncSmash for a bit (this attack can take HOURS with a large username list, I let this one run overnight), I discovered over 400 valid usernames that could be used for further attacks. With 400 accounts like this, I felt certain that I was going to find *SOMETHING* that would get me access.
And I was right.
As mentioned before there were some SMB ports open and available to the internet (!!!) on a server. Since I had legitimate usernames, it was now WAY easier to do a password spray attack on multiple different services. I split the usernames up between different files, and then used LyncSmash on the S4B server again, as well as Hydra against the Windows SMB share to try to find valid credentials to login to the VPN. After a couple hours, I was able to find four (4!!) different usernames with a password of “Winter2018!” One after one, I tried to login to the accounts on the VPN server, and none of them were granted permissions. Hmmmm…
So, I logged into the emails of them, and did a search for passwords, eventually stumbling across a different username and password (a password reset, with the password sent in plaintext…this user was a supervisor), which had not been reset. Using these credentials to try the VPN access again, I was still unable to access the internal network. However, these credentials *DID* have access to the Citrix server. Was this an oversight? Did this employee need access that the supervisor didn’t have? Weird.
Anyway, after gaining access to the Citrix server, privilege escalation was fairly straightforward. Now that I was on an internal network, I was going to be able to use some of the old tools of the trade to find who was an admin, and then attempt to get their credentials where possible.
First things first, I downloaded Responder for Windows, and ran it in Analyze mode, just to see what was out there. After being satisfied that I wasn’t going to break anything (at least not that I could tell), I started Responder up, and let it run for a bit. I captured a couple other hashes, but no Administrator level users, so I turned it off. I checked for antivirus on the server, and I didn’t find one. No AV on a server is certainly not a good practice, but it’s really not out of the norm. Most sysadmins don’t like running AV on servers because of the performance impact it can cause, but to be honest, it really does help to have it on there, and depending on the server (and how the AV is configured), the performance impact is minimal. If AV was on there, I might not have been able to pull off the next piece of the puzzle: getting a Metasploit Meterpreter shell on the server.
For my next trick…
I created the Meterpreter payload, and put it in a Zip file to try to see if I could get it past any defenses at the perimeter. I setup a quick and dirty Python webserver on my attacking server, and then used Internet Explorer to download the Zip file from my attack server. I saw the file being accessed from my webserver, but the file wasn’t making it to my victim the client server. The client’s perimeter firewall (with AV!) was catching the Meterpreter shell as I was trying to download it to the internal server. Great job!
Being that I was having these issues, I decided it was time to encrypt the Zip file, so I put a password on the file and tried to download it again. This time, the file was grabbed from my attacking webserver, and I had no problems getting it on my victim. Welp.
After starting the Meterpreter session up, I was still a limited privilege user, however, I knew that there were quite a few servers on this network that I could try to exploit (they were a part of the internal scope, which I had not started on yet). I setup my Meterpreter session as a route point to the internal network, and then started using Metasploit’s MS17-010 vulnerability scanner payload to find other servers on the network which may be vulnerable to the NSA EternalBlue exploit, and I found one. One server out of hundreds which had been unpatched. An old, forgotten Windows 2008 server which the IT team didn’t even know existed. I exploited that server with the EternalBlue exploit through the Meterpreter session, and from there it was easy pickins. This particular server had a Domain Admin-level service account logged into it, with a password that hadn’t been changed in 4 years (I found this out a little later in the debrief session). I was able to use yet another Meterpreter shell on the system, and from there, I used Sysinternals’ ProcessDump to dump the memory of the Local Security Authority Subsystem Service (LSASS) process, which is the service responsible for handling aspects of Windows logins, including logging on to the server, access tokens, and password changes. On older versions of Windows (2008R2 and lower), it contains the plaintext passwords of users who are logged in. After dumping the process memory, I securely downloaded it to my attacker system, and then used Mimikatz to read the memory. As expected, Mimikatz was able to pull the plaintext password from the LSASS memory dump, and I was able to use this password with the service account to roam around the network and find various pieces of data related to financial records, and proprietary info related to an upcoming project for my client that many of their employees didn’t have access to.
Are you scared yet?
To borrow from the tagline of Phantasm – As an IT administrator, if this one doesn’t scare you, you’re already dead.
So, what we did we learn? There are several ways that this client could have protected themselves from an attack like this…let’s go through some of them.
- Weak passwords are bad. If you’re using any kind of weak passwords – any form of the word “password” in one is bad, or seasons, or your company name, don’t. Just stop. Right now. You’re making it too easy on guys and gals like me.
- Inventory your network. This is super important. After I gained access, there was that one server which was unpatched. It was completely forgotten about, and no one had scanned the internal network for quite some time to find it. Complacency can get you killed on your network
- Patch, and patch often. This goes hand in hand with #3 above. There was a patch available for this server, and it should have been caught with some regular scans. It wouldn’t surprise me if there were a couple other servers or workstations which weren’t patched.
- Install AV on your servers. Antivirus is not completely a nuisance. It does serve a purpose, and quite often it will save your network from low level attacks. Granted, it doesn’t completely keep me from doing my job, but it does make my job that much harder. AV at the perimeter is great, but once an attacker is in, they’re in.
- Make sure that your firewall is configured properly!! Why was SMB open to the internet? This shouldn’t ever be exposed. EVER.
- Do internal audits of your users as well. One of the misconfigurations we run into often is that some users have access to certain services that they shouldn’t simply because they were copied from another user account, without checking that the template account had all the correct permissions. Quite often, we see user accounts that are given complete administrative access to certain machines, or (and this has happened more than once) the Domain Users group is in the Domain Admins group. This is great for me! Bad for the company. Don’t cross the streams. Do internal audits. Period.
- (Get ready for the obligatory Sales Pitch!) Are you troubled by strange traffic on your network? Do you experience feelings of dread in your network closet or server room? Have you or your IT team ever seen a spook, spectre or ghost? If the answer is “yes”, don’t wait another minute. Pick up the phone and call the professionals: TRUE DIGITAL SECURITY. Our security experts are ready to help you take steps toward a stronger security posture today.