My name is Walter Cuestas and I'm from Peru in South America.
I'm going to talk about a vector that is not very commented or used at red teaming exercises.
And this is about using applications as the initial compromise.
The not so classic Juanma in this case.
I want to point out that everything I'm going to explain is what we've learned with the team I belong to.
We are working together for several years doing pen testing and red teaming.
Actually in some cases for more than 12 years.
So you will see some examples of our collective effort.
And the question may arise, why two applications?
There are several reasons.
Because we believe that red teaming is not only about getting domain admin or root.
Because not always having that power means you can access data.
Not every application is integrated with Active Directory for example.
After some interaction with people on shares of threat management and hunting.
They are so concentrated on AD and Windows 7.
Organizations are not integrating application security yet in their effort to enhance security.
Also defenders are always pushed to be warned about social engineering attacks.
Or how attackers are bypassing endpoint security.
Or the last password spray technique to common services such as email.
Someone could say that applications today are in the cloud.
But we are seeing that few companies are migrating their core to the cloud.
They still keep it on-premises and modern applications just need to go down to the core.
And finally, because as all of us know, remote access services are delivered through web applications.
One more reason, besides this happens in every other aspect of security.
Is that applications suffer of the same problems for a long time.
As you can see in this image from exploit.db.
This is not only true for common applications, but also for embedded ones.
We can see a Cisco device suffering from local file inclusion.
And a very old kind of vulnerability in the application field.
We want to share this small framework.
We developed it just to have an order in what we do during regular exercises.
I am not going to cover every module, just some high level about information gathering and enumeration.
And more on initial compromise, of course.
So let's talk about recognition and especially about OSINT.
As you know there are tons of tips, sources and how-tos about OSINT.
We want to focus in some aspects.
Searching DNS information is crucial.
And it is important to know that we don't have to select just one tool for that task.
Indeed, most of the time we have to aggregate the results from several of them.
Search engines, such as Shodan, Census, Sunmine for example, are most useful here.
Because we don't have to touch our target at first step.
And these engines keep current data most of the time.
Also, today a good search on surface internet is better than going deep.
And special attention must be on source code leaked in the most innocent and honest ways by developers.
And documents that you have to read very long documents.
So, we have a lot of tools and a lot of data.
And let's talk about real world.
There is no magic neither perfect tool.
And there is no way to learn about our target organization without doing manual investigation.
Spending hours reading information and taking notes that we will share with the team.
Another fun moment is when tool is not working as expected.
Or we need more from it.
That's when our developer skills are important and we start to feel happy.
After a bunch of data, you need to give some form of order to this data to do your analysis.
And it could be very simple.
Just use human readable names for directories and files.
I mean, not only for you, for the whole team.
And you need to do a simple select to get data including images.
There are very good tools, but if you don't have time or just don't want to install them,
SQLite is a very good option.
Then, what do we reckon?
For us, the most important rule is not to underestimate your adversary.
Who is your adversary?
The blue guys, of course.
We believe that not every admin is fool and not every developer makes applications without security in mind.
And not every threat hunter is just looking for a DE event.
At least I guess so.
As we are going after applications, there will be a moment to scam something in a very smooth way.
Not now, as blue team is expecting that.
Also, we are going to use the same techniques and tools as when testing applications.
But we have to forget about OWASP, for example, because this is not a pentest neither a bug bounty.
Let's start with initial compromise.
And a small note about these cases that came from real world.
In one case, we were able to create the same scenario we found in another one not.
The main reason is that we don't get the same applications versions of the ones that we got during red team exercises.
So, case 1 is here, we call it jumping.
Because we are going to jump several times.
The scenario is like this.
This is a very common scenario where an organization is using cloud for new applications.
Hybrid cloud may be the right name.
We have the frontend of the application, the cloud, with a database.
But it needs data also from the business core applications.
And data that are still on-premises.
We are looking for the secrets on that core because it's the most valuable information.
And as happens today, there are so many digital transformation projects and few security controls.
Everything is sales-driven.
I know that this seems like a hack the box case, but it's not.
Our first security test for digital transformation projects showed us that there is no control over the initiatives coming from different teams in the same organization.
So, our recognition found this exposed Jenkins administrative interface.
In fact, it's exposed to the internet.
With the option to create an account which is not a default.
This is not a surprise. This is a very well-known issue.
But, what is bad is that by default, locating users can do anything.
Having this in mind, let's take a look at the credentials section where we found this case.
One for SSH access and the other one to get access to the cloud.
One is an Amazon XSK, but this is not enough.
We need also the secret XSK.
As you can see, it seems this is properly secured.
One of the things we learned from doing pentesting on applications is that client-side source code is something we always want to review.
Just use developer or inspect mode and you will find not only HTML and common JavaScript.
There are still developers that trust on client-side protections.
And not exactly related comment for this slide.
Today JavaScript is very powerful at client-side.
So, there are more reasons to review that code.
But, as we can see, this case is encrypted.
So, let's move on and check the SSH key to gain remote access.
But, once again, this key is also encrypted.
Now, Averik, today there are tons of information that we want and like, of course, to read, view and listen.
And when talking about writing, there are no magic scanner working for us.
But, there are several cases where you won't find any previous information and this is when you get a research moment.
Jenkins itself needs a way to decrypt that information in order to use it.
And it has an option to run a script that we are going to use.
As you can see, Jenkins provides all we need to do our job.
A small and simple script will do the magic.
And, voila, we got our case decrypted.
So, we use them to access the cloud with the same privileges as this project Jenkins have.
Will be them for production environment?
Well, let's take a look.
It seems clear that we are looking for instances as long as these credentials are used in an application project.
We found the information of an instance and the corresponding IP address.
Let's check it.
Well, it's obvious that this is not our target.
Maybe we can use it for our first jump, but it's not what we are looking for.
Let's try with the other kind of access.
I mean, accessing by SSH.
And we are to focus this time on searching source code and review this code.
So, we start using the SSH key we got.
And we got access to the cloud by SSH.
And start to search for code.
And we found some programs here.
The first element to search, we are looking for endpoint information as long as they will show us some new paths, maybe credentials.
And we got this config file.
As I said, we can see that we got an endpoint and a set of credentials, username and pass.
And, of course, the API text means that we have information to access an API.
And, of course, it will be a RESTful API.
Checking from inside the cloud.
We use a cure and we got an answer.
So, endpoint exists and could be working.
Also, we got a redirection.
And take a look that there is a cookie with a JSession ID.
It smells to Java, besides the code analyzed was PHP.
But we need to be more comfortable with a browser and other tools.
So, using this SSH connection as a proxy and configuring our browser, we can see that we are identified with the IP from the instance.
Also, when browsing an API URL, we got another application related directly to the previous one and the API.
But we have no access to other databases.
Only the API is exposed to the cloud instances.
Just from the cloud instances.
Our real target is on-premises with core applications, the legacy ones.
Do you remember the JSession ID cookie?
Well, that and the app server listening at 8080 port seems pretty much like Tomcat.
It's better to make regular traffic with a browser or cure to do banner grabbing.
I mean, we are not going to use our nmap, for example.
And checking Tomcat related ports, we found 8009 port open for the Apache JServe protocol.
This AGP is a binary protocol mainly used for reverse proxy between front-end web server and back-end application server, such as Apache and Tomcat itself.
It's shorter, faster and, of course, vulnerable.
Ghostcat was announced this year and this vulnerability allows arbitrary file reading and Java server pages, JSP, processing.
It means real-world command execution.
And, of course, there is AGP shooter to exploit it.
We are going to start using proxy chains as long as this tool is not proxy aware.
And since now we will be searching for configuration files mainly.
Finding an abloved servlet doesn't mean everything is easy.
Let's review that servlet source code.
Again, getting the file with AGP shooter, we found the abloved directory.
And it has some security control.
It accepts only JPJ or PNJ extensions.
So, we are going to use a simple web shell to start.
We don't want web shell with fireworks.
First task on arrival is to change the image name station from JPJ to JSP.
And remember that Ghostcat allows for JSP processing, but you don't have to use that extension to ask AGP shooter to do that for you.
Upload and execute our special image.
Just a cure for the upload.
And of course, AGP shooter for execution.
This script accepts two parameters, read and eval.
Eval is for processing the JSP.
And as you can see at the bottom of the last image, the first command to execute is rename the JPJ to JSP.
So, we start doing enumeration.
For example, we are using an account called Tomcat.
It's a limited account, no high-level privileges, but we can do some network enumeration.
And we are going to search for configuration files.
After that, we realize that we need to use an improved web shell.
So, we upload this one.
Searching through the configuration files, we found another endpoint and more credentials that are not from the cloud instance, neither the Tomcat server.
You could ask MySQL in the core.
Well, actually it was Oracle, but MySQL was enough for recreation.
We are going to connect to this database server.
And hopefully we will find the core secrets.
Let's use the options of our improved web shell to connect to the database.
And when showing databases, we could see that this is not the precious secret we are looking for.
Also, this account doesn't have enough privileges, so we have to try harder.
Well, we tried harder and found another set of credentials in another configuration file for another application.
Same endpoint, but different credentials.
Let's try these credentials.
And finally, we got the core secrets with maximum privileges.
From here, we can dump data and exfiltrate it.
We can modify, add or delete databases.
We didn't own the domain, we owned the database.
So, here are the secrets.
Some questions and tips.
I guess that someone is monitoring this kind of activity, maybe those application firewalls that are looking for injections or sophisticated malware, not this kind of normal traffic.
When we do red teaming, we start with a couple of red teamers, not extra ones as needed, just to have people with enough skills and experience.
Indeed, also during pen testing, reviewing source code is a must.
Sometimes, developers and admins follow guides strictly and keep some information that is not mandatory to do so.
Maybe this is a new kind of default credentials, but we found cases in sample code from howtos in some application's production environment.
Just one note, I was kidding when I said that this is normal traffic, but you understand that this is not a kind of sophisticated traffic that we read all the time in the news.
Sometimes, it works better because protection devices are waiting for that sophisticated traffic.
So, what's next?
At least for us, main objectives are doing a red team exercise, is to test the time to detect and time to mitigate.
But let's face it, most organizations just want to have an almost real-world experience with attackers, and real ones are looking for ways to get money from their attacks or some kind of power.
So, let's think as them and elaborate ways to exploit the information.
To keep everything organized, we have to add this initial compromise with our C2, my favorite one is push, of course.
There are command executions in a couple of jams, maybe it could be useful for lateral movement.
Let's move on to case 2, dynamic duo.
Remote access is required, before COVID-19 it was needed and after this is a must.
But how is this kind of service related to applications?
Well, as long as these services use protocols like HTTPS, as long as the users and admins use their browser to do their thing,
as long as these interfaces are using HTML, JavaScript and running CGI and several scripting languages,
as long as they bleed also, I mean, they have common application vulnerabilities also.
This is our scenario for this case.
This company has two remote access servers, Y, migration, backup, both integrated with Active Directory, a perimeter with some good protection.
They can't work together, we are going to see how.
By the way, this will be the traditional red teaming, getting domain admin from the beginning.
Let's find out what is the origin of these vulnerabilities, or when we realized that these vulnerabilities exist.
Last year, these researchers showed several vulnerabilities they discovered on SSL VPN appliances.
After that, exploits started to appear.
But, as every people that knows how to use a GAN, this is not just point and shoot, you have to know how your GAN works, how your tool works, and take care of your GAN or your tool.
In the more traditional service, there are always several exit paths to command execution.
So, let's start with one of them, Pulse Connect Secure.
One of the vulnerable appliances showed last year was this Pulse Connect Secure.
There are several versions affected.
Again, we found an administrative interface exposed to internet.
We have several credentials to try coming from recognition, but maybe doing some kind of password spray to this device could start the alerts.
So, maybe we shouldn't try them, and we are going to do some kind of special recognition in the way that we tested applications.
Why don't we try with a proxy like Burp?
As in case one, we keep updated, reading, viewing and listening a lot of information. Actually, we like that a lot.
So, checking if this device is vulnerable to pre-authentication, arbitrary file reading is as easy as to send a request.
We are using Burp just because it is our favorite tool for applications security testing.
And as we can see, this appliance is vulnerable.
We are reading files like PulseWD with a list of users and several other files, such as the one with a host registered manually in this file.
So, this device is vulnerable.
And we are going to use a script, which Fox made a bash script to exploit this vulnerability.
Also, we want to give a small recognition to all these young people helping others automating the exploitation.
That's the reason of that small white message there.
This script will download several files.
Some are pure plain text and some are data structured in another format.
All contain critical information, case, usernames, passwords, IP addresses, operating systems of users and so on.
For example, we got local users that are active directory users if the appliance is integrated with that directory service.
And also VPN logins that are usernames with passwords all in plain text.
Yes, 2020 there are still security appliances storing credentials in just plain or clear text.
Also, we got SSH keys, but we are not going to use them because external firewall is doing its job very good.
So, we have another group of information.
We got clear text credentials.
And we got inside Pulse Connect Secure with user level credentials.
Just that, just loose user level.
That's not too much to do with that.
But some usernames have a kind of active directory look and feel.
And they weren't on clear text.
We got the hashes of the passwords.
So, John the Ripper came and did its thing.
Cracked hashes.
And after that, we got access as user.
Also, not too much applications delivered for end users.
And as admin.
So, doing more checks, there is integration with active directory enabled.
As we can see with these authentication servers.
And for that integration, of course, you need an account to access the active directory.
An administrator level account for active directory.
So, we got domain admin.
And yes, as you can guess, there is credential reuse in this organization also.
But then, this thing doesn't stop here.
Because this software is also vulnerable to command execution.
So, after doing some enumeration of users.
And testing if we can reach the domain controllers of this active directory.
We went for command execution.
For this, we need credentials. We have those credentials.
Because this vulnerability is post-authentication.
We can inject commands and execute.
There is a public exploit.
This is another exploit made in Python.
And what it does is take credentials we got.
And do the magic to allow us to connect to the appliance by SSH.
What it does is download our SSH case to the appliance.
But there is a firewall, as I said, that doesn't allow to connect by SSH.
So, we have to do small modifications to the script in order to use it.
As you can see, just comment some lines.
And add parameter manipulation.
Plus, we are going to use burp for the output.
This script is proxy-aware for debugging purposes.
So, we don't have to add anything about that.
And now, we are executing commands on the appliance.
So, question arises, is this enough?
Well...
As there is a robin for every badman or vice versa.
We got PulseConnect secure.
And it has Citrix right by its side.
That was perfect for us because having only one foot inside.
Is not enough.
And... guess what?
Credential reuse is everywhere.
We got access with same credentials as the ones in the other appliance.
Of course, they are Active Directory integrated.
And in this case, it has more applications deployed.
And we started to check one by one.
Special focus in traditional Windows applications delivered using distinct clients.
Because there are several ways to escape to Windows Command Shell or PowerShell.
So, this application looks as the one we are looking for.
As you can see, it loads an instance of Windows.
This is the application starting.
And this is the application login pop-up.
Escaping from Citrix jail has a long history from several years ago until today.
At first, it is based on pressing some keys on the keyboard.
For example, in this case, pressing CTRL plus ALT plus DELETE does a trick.
In other cases, WINDOWS STICKY KEYS, pressing SHIFT five times or ICA KEYS from Citrix.
To gain access to CMD or PowerShell, you can use dialogs such as FILE AND OPEN or FILE AND NEW TASK from Task Manager as you will see.
There are more on this to bypass file restrictions.
There are several documents showing how to do that.
So, TASK MANAGER, NEW TASK, CMD EXE and we got CMD in action.
From there on, we did some enumeration, classic WINDOWS and AD enumeration.
But more important, search for valuable information.
To tell the truth, you can see that we found here some files with credentials and IP addresses.
But in this case, we just confirmed that this kind of information was accurate and updated.
Because we got this information in one repository on GitHub during recognition.
After this, we are going to see the light in terms of infrastructure penetration.
Because good network segmentation is still a dream.
There are yet several exceptions breaking ACLs.
And in 2020 is not true that only end-users are good victims.
We are going to try to shoot to developers, internal and external ones, IT people and security people.
Why? Because they have more power on their machines than end-users.
As simple as that.
Some tips about this kind of initial compromise.
We have two doors opened.
In that moment, it was important to warn the customer about that.
The customer had to warn the subguides.
Also the prevention, correlation and event management solutions had to be warned.
It is important to be as smooth as possible.
But there are some cases that you cannot wait to end the redteam exercise to warn the customer.
Also, as part of these smooth actions, you should avoid to create accounts.
At least not god-level ones.
It is better to use a simple user account and give power to that account.
In some situations it won't be possible, so do that, create an account after several checks.
Always keep logs in mind.
And of course, delete just entries belonging to your work.
Remember to never underestimate to your adversary.
Be patient, this is not a game, and this is the reason why redteam exercises has enough time.
Have fun, of course.
Finally, I want to thank Omar and all the crew at Redteam Village.
They do an awesome job all the time, just for giving back to the community.
Ciao!