Skip to content
 
Episode 51

Privilege Escalation Using HackTricks with Carlos Polop

EPISODE SUMMARY

In this episode of 401 Access Denied, we're joined by Carlos Polop, security researcher and creator of Privilege Escalation Awesome Script Suite (PEASS). Seen recently with the Linux "Dirty Pipe" vulnerability exploitation, it's become critical to learn how attackers exploit privilege escalation flaws. Carlos shares how pen testers can use LinPEAS and WinPEAS to expose vulnerabilities in CTF environments. Additionally, learn how you can contribute to his research in the penetration testing community.

Check out Carlos' book: https://book.hacktricks.xyz/ 
Follow Carlos on GitHub & submit pull requests: https://github.com/carlospolop 
Join Carlos' Discord community: https://discord.gg/hRep4RUj7f 
Follow Carlos on Twitter: https://twitter.com/carlospolopm 

Subscribe or listen now:  Apple Podcasts   Spotify   iHeartRadio

Joseph Carson:
Hello, everyone. Welcome back to another episode of 401 Access Denied. I'm your host for the episode today, Joe Carson, Chief Security Scientist and Advisory CISO at Delinea. And I'm really excited about today's podcast. I've got a very special guest on, and it's something... I've known about Carlos for a long time, but it's a pleasure to really get to have a really in-depth and fun discussion. So Carlos, I'll pass over to you to introduce yourself, and it's a pleasure to have you on the show today.

Carlos Polop:
No, Joe, the pleasure is mine. Thank you very much for having invited me here. I'm very excited to be here with you, discussing the topics we are going to discuss. I don't want to do any spoilers. For the people that doesn't know me, I'm Carlos Polop. I am the guy behind HackTricks, the PEASS, PurplePanda, and these open source resources I dedicate to cybersecurity. And at the moment, I just work as senior security engineer in a FinTech.

Joseph Carson:
Awesome, and for me, I think in every pen test that I've involved into and ethical hack and even incident response, I get into a lot of incident response. And one of the biggest things that always gets into me is how easy it is for the attackers to escalate privileges. And it's something you see all the time. I get involved in a lot of Capture the Flags and online events and for me, it gets going through. And one of the things that always fascinates is the privilege escalation piece. Is the one that gets me excited, once I get the initial foothold, I really get excited about how do I elevate the privileges right up to either root or domain.

Joseph Carson:
And a lot of the tools I use in order to do that... In the live ones, I kind go more manual. I take the manual approach because you want to be less detected. You don't want to be as noisy. But definitely one thing that I go to all the time is linPEAS and winPEAS. They are really awesome and I've always loved automation, for me, automation is the way to go.

Joseph Carson:
So Carlos, it's amazing. And I'd like to also kind of... Where did you get started with privilege escalation? What was the background? Why did you write the scripts? And even the awesome, the book on the HackTricks was fantastic as well because for everyone, it's a go to reference in order to make sure that we're actually going through each step along the way and elevating.

Carlos Polop:
Well, it's a pleasure that you say that I am really proud of HackTricks and the PEASS, and I really enjoy people using it. So why I started it? You mentioned it a little bit, obviously when I need to be as stealthy, I also doesn't launch linPEAS because that is going to be very noisy, the same with winPEAS, I try to take a more manual approach. But I think that before linPEAS, winPEAS and these scripts in Hack the Box machines in this kind of Boot-To-Root, CTFs where you need to study privilege, most of the people were doing this manual job. And one of those people at the beginning was me. And I'm going to be honest, I hated that part of the machines because I will always do the same. I will just go to this blog post and start copy pasting all the things.

Carlos Polop:
At some point, I will just put them in my own local blog and copy paste from it. I just hate it because it was always the same. At some point you will find it, but why do you need to do this manually? And by that time, I was preparing for the OSCP and it was Friday that I wouldn't have enough time to enumerate properly the machines and find the privilege escalation. So I just start doing my own scripts. And at some point I just decided to put these colors because I knew I was going to be pretty nervous for the exam. So I say like, "Hey, put red color." So I know where I need to take a look. And actually I started linPEAS and winPEAS, but not the version we all use now, but the patch version-

Joseph Carson:
The patch phone. Yeah. Yep. The patch phone. Yep.

Carlos Polop:
The OSCP machines were kind of fault and the dot net weren't going to work. So I just created this patch version just to numerate them fast and try to find escalation path. So I guess the OSCP has part of the fault of creating these kind of scripts.

Joseph Carson:
But to your point, one of the things that, yes, as doing penetration tests, I go to the manual method. When I'm doing Capture the Flags, I go to the automated methods of linPEAS and winPEAS. But as a defender, I also use it as a defender to go through even when I, for example, go into organizations, doing incident response, I think for organizations should also be running these as a defensive capability too, because you want to find out if you've got misconfigurations, you want to find out if you've accidentally stored credentials in the deployment of a machine. So I think, just from an attacker perspective, but from a defender perspective, these are essential because a lot of cases are the things that go missed or not checked. So, I mean, for me, I think this is more important for defenders to be using these tools more importantly than even just the attackers.

Carlos Polop:
Yeah, yeah, yeah. Actually I got this conversation maybe a couple of years ago and about a person that had exactly the same mind of you, had the same question and he was telling me like, "Hey man, I was giving this image, is there any way I can run linPEAS on it? So I can check the results and find misconfigurations." And at that point, I didn't thought about it, but he actually answered himself like two minutes later, he just told me, "Hey, I did chroot over the image and I rode linPEAS. And I found the misconfigurations they had." So it's completely true what you say, if you're a defender, you can just run linPEAS in your machines to try to find this misconfigurations, fix them. But even if you're doing a forensics job, or even for example, I'm now using it to check some firmware. You can just Mount the image, use chroot and just run linPeas and try to find some misconfiguration that linPEAS is already looking for.

Joseph Carson:
Yeah, absolutely. Because that's the thing is, even when you look at these for... Things can always be used for good and bad, but I think the benefit here is that for the people who's defending, they will get a lot more value being able to harden machines and to be able to configure and put the right things in place to make it as difficult as possible. Because for me, I like it to be a challenge. So I do. So one of the things I'd like, for privilege escalation... I mean, from Windows to Linux and other platforms, how different is it in regards to the steps and processes? Are they very different in your experience? Or do you find it the same techniques used?

Carlos Polop:
Well, the main difference I usually find is that in Linux you have Bash and in Windows you have Batch or PowerShell. If you're not used to Windows, that might be a problem, definitely. Well, I mean, you're lucky, of course you now can have passing Windows, but that's not usually the case in the system. From the techniques perspective, I think they have a lot of differences, but they also have main techniques that are quite similar.

Carlos Polop:
So regarding the differences, when I started creating this linPEAS, winPEAS, I think the goal and language was starting to be known and a lot of people told me, "Hey man, why don't you just create one privilege escalation and go." And the answer was pretty straightforward, even if they have some techniques in common, most of the UNIX privilege escalation techniques are only in UNIX. And most of the Windows are only in Windows. Like you're not going to be looking for Azure ID binaries in Windows.

Joseph Carson:
Exactly.

Carlos Polop:
Or you are not going to be looking for unquoted service paths in Linux.

Joseph Carson:
Correct.

Carlos Polop:
And like this with hundreds of different techniques. So it didn't make any sense to create just one.

Joseph Carson:
Registries are very different as well. The one thing that you do find probably that overlaps is the way configuration files are done. Probably if it's XML or JSON or whatever it might be, the configurations might be the same way, but you're absolutely right. Registry services, libraries, user profiles, if I find them, they're very different techniques. You go through the same process if you look at the OS and then of course you go into the users and you follow the same process, but I find them very different techniques in both systems.

Carlos Polop:
Yeah. I try to follow the same process because I knew that people were going to be more comfortable with Linux and the other people were going to be more comfortable with Windows. So even if they are completely different tools, if they have that similar structure, people is going to find them easier to read. And obviously I put all these HackTricks things because that was actually for myself because I couldn't learn hundred things of privilege escalation techniques. And I knew that probably in a couple of weeks, I was not going to remember what was those techniques. So I just put those links saying, "Hey, man, just take a look here, because here everything is explained."

Carlos Polop:
Anyway, you also introduce the similar techniques. I found that in Linux and Windows are very, very, very common way to escalate privilege, or just permissions misconfigurations maybe you can read or you can write things that you shouldn't be able. And that's a common thing they have. So actually, if you go to the repo, you are going to find some jamels files, where in this case, I am putting all the known files I know that might be contained in passwords.

Carlos Polop:
And in case of linPEAS, part of the linPEAs course is created automatically by Python reading these jamels. And in case of winPEAS, that jamel is going to be in bed in the binary. This means that the common thing they do that is looking for these files. And soon enough, we can talk about this later. They are going to look also for regex and the thing that they do in common, they actually do it in common. I don't need to maintain both lease independently or anything like that because I try to do that and I don't recommend it to anyone.

Carlos Polop:
So the common parts are actually pretty common. So, that helps me a lot. Like every time I do a new Hack the Box machine, I know I'm going to learn about a new software. That is a story, new password in a new different file, before it took me maybe half an hour just to make sure it works to put linPEAS, to put in winPEAS. Now I just go to this jamel, copy paste something similar I want to do, change the names and in less than one minute, I have the new linPEAS and winPEAS will prepare to catch this new file.

Joseph Carson:
Yeah. That's awesome to kind of at least to make it as efficient as possible and look for the similarities across both platforms. What are some... I mean, when I'm doing a lot of the kind of machines in Capture Flags, on occasion, of course you do find the kernel bugs, which do occur. What's the primary, as you mentioned, misconfigurations about reading access files and writing to files? Is that the primary method that most attackers are able to successfully elevate privileges? Or what would you find be the most common... I think a Windows probably services might be kind of a common way that misconfigured services of write and folders or unquoted paths. But what do you find is the most common?

Carlos Polop:
I mean, I think it will depend if it is a CTF or it is production live, whatever machine. I mean, CTF, they... Well, you may find the Azure ID Binary in all the ECTFs and that's everything you need. In RCTF, you may find maybe that you can access some pseudo tokens in other process, maybe that you can modify this service file, or maybe that you can modify some folder where you can indicate the folder where the libraries are loaded from, and then you can write your own library that will be loaded into the binary.

Carlos Polop:
There are definitely a lot of different things, but in live machines, I can tell you that the most common thing to escalate privilege are credentials. Like in maybe 90% of times that I, well, doing my job, I managed to get inside a machine or anything. You are going to find some credentials. You're going to find some token, some from them, even if you cannot escalate privilege internally, you're going to be able to escalate privilege probably to externals platforms or even using the metadata endpoint. You will find some useful tokens.

Carlos Polop:
From the Windows perspective, I think is the most common thing in both CTFs and live machines are going to be misconfigured services. Like for some reason, I continue seeing that misconfiguration that everybody knows about. And I don't know why people are still committing the same errors. Another kind of common things I see in Windows machines is that maybe you can just write to the web server and write into the web server. You're going to be able to escalate to a new user that will probably have a better token privilege that will allow you to escalate privilege, also kind of common in Windows and not that common in Linux.

Joseph Carson:
Yeah. Some of the methods in the real world scenarios that I've seen used by mostly kind of ransomware criminals was around unfortunately, organizations giving local administrator rights to users on systems. I don't know if they have this perception that by giving local administrator rights is that it's limited to the one device and that users only. I don't know if we should get Microsoft to re-change it from local admin to being an administrator irrespective, because one, I find that the attackers find that they're on a machine with local administrator rights is literally three or four steps that they have to change in the configuration of that machine. And luring what they tend to do is they try to lure somebody with domain administrator rights, then to log on after making the registry changes so that they can run Mimikatz.

Joseph Carson:
Of course, even with local administrator rights, I've seen them using things like GMER, which we typically use to check if the system has kernel exploits or back doors or rootkits, the attackers are actually using it to see if there's any security solutions that's monitoring their activities as well. So they're actually using GMER to look for security solutions that may not be visible in the interface. So it's always interesting to see how things are being used, but with local administrator rights, literally they're able to end the disabled security on the system. Even if it's only for maybe a few minutes, like three or four minutes at time, the sessions are quite short, then basically making those registry changes and then kind of clearing their tracks and then they wait for some domain admin to log on.

Joseph Carson:
And that basically is literally they come back and they've got full domain admin rights. So just waiting for those moments, that's what I've seen most commonly is unfortunately over-privileged users having too much right to lure you to change the configuration enough in order to find ways to elevate privileges. So that's what I commonly see in the kind of incident response or digital forensics, but more, yeah, in a exploitation or misconfiguration, definitely service paths and registry is the more common that I do see in a Windows side.

Carlos Polop:
That's why privilege escalation is not fun. There are thousands of ways to do it wrong and allow people to just escalate privilege. And also something you said about these ransomware groups, I want to say that linPEAS or winPEAS are made for pen testers and from defenders to improve the security, because I saw some of those groups using them, the defender should use it before them because they have access and fix all these misconfigurations.

Joseph Carson:
That's exactly what I was mentioning earlier. It is definitely best defenders using it first and using it in a way that allows you to harden your systems and defend and correct, because like all tools, even I see ultimately PSExec being commonly used. And PSExec is something that has been great for system internals and win internals for many years. And we heavily depend on it to manage and automate the environments. But yeah. Primarily, you can never stop things being used for both good and bad, but I definitely recommend the defenders to use it first. It's definitely, I think that this is what it allows us, because otherwise the attackers are going to use the manual methods anyway, and they're going to use the same methods as we mentioned earlier, when you're doing a real live system, you're going to do the manual methods.

Joseph Carson:
You're going to know how to do the manual methods, but defenders sometimes may be not have all the knowledge and all the skills all the time. So yes, better running the automation linPEAS and winPEAS to really get that visibility quickly and before the attackers find it. For me, it's essential better. I was always once told that it's better to stop the system from being compromised than it is to restore it later. And it allows a better state and the business to be more resilient as well. So question, one of the things... I've seen a lot of things where in recent months, and even the past year, of course I've seen a lot, of course, a lot of organizations have moved to Cloud and SaaS and other types of environments.

Joseph Carson:
I've seen things like Azure and AWS becoming very popular, kind of used. What about privilege escalation in Cloud environments? What do you see? It is different slightly than it is on premise because you're dealing a lot with different roles and different configurations, but what are you seeing with Cloud systems and privilege escalation in Cloud?

Carlos Polop:
I'm glad you asked me that questions because then I can do some spam of my latest tool called PurplePanda. And you can just find it in my GitHub repo.

Joseph Carson:
Yep. Well make sure, I'll definitely make sure to include the HackTricks books and the GitHub repo in the show notes, so people can easily find it. So we'll definitely, for the audience, we're going to make sure that all the links are included so you can easily find Carlos's GitHub and the HackTricks.

Carlos Polop:
Perfect. Perfect. I appreciate that. So about privilege escalation in Cloud, actually the past months, I have been a little bit absent from Windows and Linux privilege escalation and I have been more dedicated to well, Cloud privilege escalation, mainly to platforms related to CI/CD pipelines.

Joseph Carson:
Okay.

Carlos Polop:
Because I found very interesting how the whole way of the pipeline can be compromised and there is not much about it outside. There are not much research about, "Hey, if you find this platform, you can do these things. Or if you find this platform, you can do this thing." So I have been mainly doing that job. So you say it's pretty different from Linux and Windows privilege escalation, and I completely agree because you are not attacking an operative system. You are attacking... Well, you can also be attacking operative system, probably the most related part between Linux and Windows and Cloud in a normal environment is the fact that you are either going to be able to find these tokens in that machines or that you're going to be able to talk to these metadata services somewhere and you're going to be able to steal some tokens.

Carlos Polop:
But from that point, they are going to be completely different. In Cloud, you need to know how the cloud, how the platform, how the SaaS application is working completely because different platforms are going to have different privilege escalation techniques. For example, if we take a look to Kubernetes with, it's like probably your own cloud, that can be also be run in the cloud, in EKS or GKE in Google, you're going to find that just for being in a machine inside of that cloud, you're going to have some permissions. You need to know very carefully what you can do with those permissions, because then you're going to be able to privilege escalate inside that platform.

Carlos Polop:
So in Kubernetes, you might find a service account that may be able to accept in another pod that will have another service account that might be able to create another pop. Then you can just get all those service accounts. What I want to say is that you have all these different permissions and you need to know what you have and what you can do with them and then explain it. But also you have more ad complexity. In case of Kubernetes, you could always try to escape to the Node. And from the Node you might be able to well compromise the whole cluster because you might find secrets of other name spaces of Kubernetes in the containers running in this Node, but also from the Node you might be able to access new credentials maybe in an AWS environment. And with this new credentials, you may be able to escape to the cloud.

Carlos Polop:
And then we are talking about, "Hey, I just compromised this small Kubernetes environment and now I can escape to this cloud." You have to do exactly the same. You have some credentials and you have to enumerate what you can do. But there is a very important difference, probably between regular clouds like AWS, like Google Cloud and things that maybe we are more common with like active directory or Kubernetes. And it's the fact that by default having just some credentials in AWS or GCP or Azure, I haven't touched too much as Azure, but I suppose it's the same. You're not going to be able to read all, to get just all the users, all the permissions or everything you can do.

Carlos Polop:
So something very important is that you have the credentials. Maybe your view is very, very limited. You see that you can impersonate this other service account or this other ... role. And then with that new set of credentials, you will need to enumerate everything again, because you might be able to see new things. And that's something nice about PurplePanda is the fact that you can just indicate as much credentials as you want and it is going to be rerun with all the credentials, merging all the discovery assets together. So finally, you're going to be able to see everything you can from the credentials.

Joseph Carson:
It sounds a bit like a bloodhound for uhh...

Carlos Polop:
Actually that's for me because I mentioned PurplePanda, but I didn't introduce it properly. It's actually kind of a bloodhound because I have graphs. I have the parts you can follow to privilege escalate. So instead of active directory, it is for a specific clouds barrel but also between them, because there is another layer of complexity added to all of this, and it's the fact that maybe you have a cloud, maybe this clouds have some users that can impersonate other users inside this cloud or inside other clouds, but then you have integration between different platforms.

Carlos Polop:
Maybe in, a common example I used to put this, maybe you have compromised a token or a user inside GitHub which can manage to bypass a branch protection and merge directly into master in a repo. By passing that branch protection must not be that hard as people might think. I'm not going to explain all the techniques, a lot of them are in HackTricks, but maybe you go to Google Cloud and you find this cloud function that is just running that repo from GitHub. And obviously this cloud function is going to be a Lambda in the AWS world. And it's going to be running with some set of permissions inside any of the clouds.

Carlos Polop:
So if you can just merge into this repo, you are probably going to be able to compromise that new account inside this cloud. So you have also this kind of integrations, or if you are storing your containers in GCR and you are running it in AKS, inside AWS, just with write access over that bucket that contains these container images and operating one of them, you're going to be able to run it inside the AKS in AWS. And you are going to be able to compromise another Kubernetes with another AWS, with a lot of new possibilities. And I'm just starting, there are tens of ways to integrate different things, different platforms with different methods. And this is just a small part of the pipeline, because then you have obviously the library repos, you have the machines of the developers, there are a lot of different steps and it's too easy to compromise it.

Joseph Carson:
Yeah. Have you used much of the version control PEASS as well? Because I know that it has a very poor job with version controls, if you just increment some of the versions you can actually overwrite because it automatically applies at any latest versions because people have switched to automatic updates and if you have right to repository, you can simply put your own with a newer version revision, just one increase and it will apply.

Carlos Polop:
Actually that's where... From where I started, I just compromised the version repository we have that developers are using to download all the libraries and so on. And obviously releases are also using it. And I just found how... Something I don't like about this probably smaller platforms that than clouds is that you can assign some roles, but you cannot Grammarly define what each person on each group can do. You will probably have like, you have WRITE access. You have read access. And you cannot say maybe, "Hey, I want this guy to be able to modify these libraries or these repositories or maybe just this, or maybe I don't want it to be able to overwrite new releases." What I find there is that most of the developers and other people will have write access because at some point they might need it and any one of them can just go there and create a new repository compromise an already created release, create a new release, like they can do whatever they want and they're going to compromise the whole pipeline.

Joseph Carson:
You remind me, when you were talking about the difference between traditional OS type of platforms in cloud. It reminds me that when I think about kind of doing pen testing new cloud systems, it's almost like pen testing an API, in many cases, it's service driven. You probably have some type of API call and you either basically writing to it or calling from it. And depending on what privileges or what access you have, you're looking to get as much information and visibility as possible.

Joseph Carson:
It reminds me one box I did on Hack the Box, not a while ago, which was, just looking up here, was Steam Cloud, which was basically a pods Kubernetes driven platform. So it was a lot of fun doing, it was one of my first times getting into doing pods and basically being able to write new pods and then elevating privileges and then breaking out of it. But for anyone who's listening, the audience would be interested in even going and trying this. Maybe even the panda might work here, but yeah, the Steam Cloud is a good box to go and try the skills out if you're looking to get into containers and Kubernetes, for sure.

Carlos Polop:
Actually I have an embarrassing story about Kubernetes. It was the fact that I managed to get to the final of this live Hack the Box event and the final box, the final machine was a Kubernetes machine. And at that point it was funny because I was playing with my mate and I told him, "Hey man, this is exactly the work I was supposed to be doing in my job, but I haven't started it. And I feel very, very, very, very bad because I didn't know how to manage this. I haven't used Kubernetes in a year. Probably the last time was when I did this Hack the Box machine." And at the end we won because the other... We didn't won, the other team lost because they just didn't patch correctly something that they started losing points.

Joseph Carson:
Okay.

Carlos Polop:
But after that, I knew I needed to dedicate more time to Kubernetes. And actually I think one of the most advanced or maybe the most advanced, publicly available in testing Kubernetes methodology, you can find it in HackTricks, it has tens of pages about how it works, how to abuse, how to escape. Yeah, a lot of them.

Joseph Carson:
I think yeah, definitely. My go-to place is definitely HackTricks and also all the payloads, all the things, the swissky payloads and also g0tmi1k. I think those are probably three most commonly used websites that I go to frequently. So yeah. I think I've even cloned the repository, so at least I have offline access when I need to because you never know.

Carlos Polop:
I use those repos a lot.

Joseph Carson:
Yeah. So outside of your own repo, which ones do you use the most outside of your own site? Which places do you go to for learning and information?

Carlos Polop:
Well, that's a tricky question. I'm going to be honest. The blog I use the most is HackTricks because I usually forget what I have written there. And I just know that I have written something about what I'm thinking. So I just go to HackTricks, to the page and look for it. So, that makes my life much easier. You say the payloads of the things is probably the second one I use the most because, well, it's very, very useful to find just payloads and start drawing things and learn about new techniques and so on. Which other ones I use? I used to like a lot, some tutorials that appears in Hacking Articles, I think it's called.

Joseph Carson:
Oh, Hacking Articles is pretty good. Yeah. They have pretty good, very thorough kind of multiple ways of doing similar... If you have a specific goal in mind, Hacking Articles is definitely a good way to go through and kind of seeing alternative ways of doing the same thing. I like that approach, is that here's a way, if you want to do reverse shells, here's a good couple of different ways you can do it on different platforms. Then what I try to do though when I'm doing any types of kind of flags, is my preference is to change the elevate locally in the machine, rather than doing reverse shells.

Joseph Carson:
Because if you practice that more, when you get into the real world, reverse shells can be a very noisy. So you want to elevate without actually creating a lot of communication. So sometimes it's good practice kind of think when you're doing it in even gamification side, you want to practice the things that doesn't create noise when you're actually doing it in the real world side as well. You want to go through some of those techniques. So what's some of your preferred ways that you like to do in regards to elevating?

Carlos Polop:
In order to elevate privilege locally?

Joseph Carson:
Yeah. Locally do the same, changing informations or creating users or?

Carlos Polop:
Oh, I think probably the thing I use the most in Linux will be to just create a patch with Azure ID bits set. And just execute it. And if that doesn't work, probably I will just change or create a new user or change the password of one user.

Joseph Carson:
Yeah. It's the least noisy perspective because anytime you're creating connections, people can trigger and my goal is to be as stealthy as possible.

Carlos Polop:
Yeah. Well, yes and no, I would also keep in mind where I am, because in lot of cases, if you just out of the blue create a Azure ID Binary, like it's so known this way of escalated privilege that I think some others is going to be triggered like, "Hey, for some reason, someone has created Azure ID Binary that shouldn't be happening." So, but yeah, probably creating just a reverse shell will trigger out of follow saying, "There is this burst pipe working and it's not ideal."

Joseph Carson:
Yeah, absolutely. And how often do you see kernel exploits happening? We do see them periodically. We saw Dirty Pipes recently appearing in Linux kernel. We have the rotten potatoes and juicy potatoes and other potatoes and many potatoes, which is... And lots of cows, dirty cow on Linux. Of course, organizations still struggle to update and patch systems. How frequent do you still see kernel exploits kind of being used?

Carlos Polop:
Well, unfortunately I have been seeing this kind of exploits most frequently in the last months and we have had these three, it was called home kit, the bulk kit exploited on the Dirty Pipe. Very, very useful. If you're an attacker, obviously all the potatoes, all the print, whatever ways to escalate privilege in Windows. So I actually dedicate winPEAS, well the PEASS scripts to find misconfigurations and not just find kernel exploits because I thought that was something that with time were going to slowly disappear. But from time to time, we have these months where everything is broken and there are a lot of unknown ways to escalate privilege. So lately I have been seeing them a lot. It's also funny to see how people call the exploits, the potatoe, the bees, the cow, like you can't have a proper meal just escalating privilege.

Joseph Carson:
It's almost like a farm. It used to be all about the furry animals. Now it's about the farm animals. So it does have these seasonal different environments where people just get on the different kind of trending buzzwords. So yeah, it used to be all the furry animals. Now it's the garden animals and vegetables. I always love that kind of the creativity that many people have are putting into these. So, a mix of some of the fun things. One of the questions I've got for you as well is that I saw recently, I remember seeing a lot of threads around the active directory PEASS that came out for doing active directory.

Joseph Carson:
For me, I typically use mostly bloodhound side of things, but I haven't got to use it, but I saw the thread about somebody creating their own PEASS branded. Was it utility? How important is it for other people to contribute to what you're doing? Are you willing to be open and get other people contributing in or calling other new tools after PEASS? Because I think it can be a bit misleading if you do see something PEASS, you think it's going to come from you.

Carlos Polop:
Yeah. I mean, to be honest, I don't think it was proper from a person that I don't know that has never spoken to me to create just a PEASS because I mean, the tools doesn't even have the output structure of a PEASS. So, I think he was just using that name for making some publicity. But as you said, community contributions are very, very, very, very important. I understand that if he wants to call him PEASS his tool, he can. And obviously I don't have any PowerShell script in the PEASS. So I tried to talk to him and suggest him that if he managed to move the output structure for a more PEASS structure, with some colors, with the banner, with disclaimer, just the common PEASS structure, I wouldn't mind to...

Carlos Polop:
And obviously after I review the code, I wouldn't mind putting it in the official PEASS repo if that's what he wants. But also I found something that I didn't like. And it's the fact that someone just posted, "Hey, I found this new PEASS, thank you very much, Carlos, whatever." And that wasn't even my repo. That wasn't even the banner of the PEASS, like people start thinking that it was my tool because it had the name PEASS and we work in cybersecurity. We shouldn't be able to be fazed that easily.

Joseph Carson:
Yeah. We should do a proper OSINT to be able to find the source.

Carlos Polop:
People is going to create the OS PEASS. It's going to be an amazing backdoor. And people is going to just start security because it's called PEASS or whatever. If it's not on my repo, you can be sure that it's not mine.

Joseph Carson:
And you have to be careful with what you're running as well. I mean, that's one of the things that I'm always adamant, and I even remember, but it was it early last year ... kind of it was flagging. I think there was the case in the OSCP exam. One of the changes you made was it was actually, was it the kernel exploit that was in there? That was actually triggering what was... Because you always have to be very careful what you're running. And that's one thing, is every time I've got images I'm going through and always checking to see what version or what's actually running in there, what version I've got to make sure that it's always legal in regards to working with the client or something like that. So, but you're absolutely right. Always review the code.

Carlos Polop:
Yeah. Yeah. Yeah. About what happened with the OSCP, I have to say that it wasn't my fault. I mean, obviously it wasn't my fault, but it wasn't my fault in a very deep level. Well, obviously people should read the code before running anything. I am releasing new versions of linPEAS, but they are mostly the same, maybe just a few things changed. So I encourage people to read that. The thing, what's happened here is that I had this exploit in Linux, which is that you can get pseudo tokens from other process of your own user. And this is escalated privilege without knowing the password of the user.

Carlos Polop:
So I put this check in linPEAS, maybe one year, two years before the OSCP, the OSCP guys decided to put this privilege escalation techniques. And I also had this technique in HackTricks for so long. So I could believe that they read this privilege escalation technique in HackTricks. They say, "Whoa, this is kind of easy and cool things to do." And they just put it in the OSCP. The thing is that for linPEAS it was... In order to know if this was exploitable, if it was vulnerable, you needed to try to exploit it. So if I was already exploiting it, I'm going to give you a shell and you're going to be rude and everyone is going to be happy.

Carlos Polop:
But then the OSCP considered that because of that exploit linPEAS wasn't an enumeration tool, it was an automatically exploited tool, and they decided to, well to not pass this guy, after that, I talked with the OSCP guys. I modified that check. So instead of exploiting it, it just tell you, "Hey, this is vulnerable. Just go to HackTricks and copy, paste the exploit." Apparently that makes linPEAS again, an enumeration tool. They agree. They allow again, linPEAS to be used. This is from day to time. I have some person asking me what is the OSCP safe version of linPEAS, everyone is, every release of linPEAS can be used in the OSCP.

Joseph Carson:
Good to hear for everyone who's listening, just planning to do OSCP. Definitely. Now you hear.

Carlos Polop:
And the OSCP people at the end pass this time.

Joseph Carson:
Yeah, they changed...

Carlos Polop:
It was a story with the happy ending.

Joseph Carson:
Yeah. We were all kind of like, I think on social media, it was a lot of us who were kind of pushing. It's like what? That's such a minor... I know things are set for people to do the skills and know the techniques and stuff, but that was such a minor thing to impact somebody. And that's so stressful scenario for that individual. So, but yeah, it's great to kind of have that compromise and have that discussion. But you're absolutely right, even going back to the active directory one, you're absolutely right. If you're going to run anything, I even prefer to modify everything beforehand just to make sure or check every payload or rewrite it in my own can I way to make sure that I understand what it's doing.

Joseph Carson:
So yeah. To see something called PEASS, you're going to do OSINT. You're going to check it and you're going to make sure it's coming from your repository before running it. Because even anyone who has fork versions sitting in their own repost, I won't touch them because I know, I don't know unless I do a comparison to see exactly what's happening. You don't know what they've changed or what's modified there.

Carlos Polop:
Yeah, no, no, no, no. That's essential, we work in cybersecurity. You should know what you are running.

Joseph Carson:
Absolutely. So question, what about community wise? How can your community help you contribute? What things can people get involved to help you? So what can the audience who's listening in, see how they can contribute to your awesome work?

Carlos Polop:
This is a really nice question because new things are coming for the HackTricks and PEASS world. So let me disclose what is going to be happening probably next week, maybe the week after, I'm going to be releasing some exclusive PEASS versions and HackTricks because my goal, knowing that a lot of people is using it, I will love to dedicate more time and even try to professionally dedicate to just create tools for the community. Because, well, I have a lot of ideas in mind that people, I think, will find useful.

Carlos Polop:
So I'm going to be creating a subscription way to access these new versions of HackTricks and the PEASS and PurplePanda and other tools. So people might contribute, yes. Paying these subscriptions, which will allow me to dedicate more time and to give better content to the subscribers. But also I want to indicate that if I manage to dedicate to the PEASS, if I manage, they give more time to HackTricks and so on. I'm not going to live along the white community. My idea is every some months merge the master versions into the community versions. So they are going to be updated every once in a while.

Carlos Polop:
And if I dedicate more time to these, probably the updates that I'm going to be doing for the community versions are going to be better than they updates I'm doing regularly, but with needing to do other things in my time. So I think everyone is going to win, but obviously it's not all about that. Actually, I would love to find people that want to contribute with code because there are a lot of new things I want to put in the PEASS, I want to put in PurplePanda.

Carlos Polop:
I would love people to help me researching for HackTricks and reporting new techniques, new ways to do things in HackTricks. So I also encourage that people that want access to the latest version of these tools and don't want to pay anything, if they are willing to dedicate some hours every week to help me with them, I will very gladly give them access to the latest things. And they can just pay the community or pay me by giving some hours and improving these tools.

Joseph Carson:
No, that's awesome. I think that's great to connect because the way that we all win together is by collaborating. That's the only way we can be successful, is transparency, collaborating as a community to make the world a safer place. And that's ultimately, we can't do it by ourselves. We can't do it individually. We can do some contribution individually, but the way we really make the world a different place, a safer place is working together. So absolutely, that's great to hear and we'll definitely make sure that if you have a link that we can add for the subscription or how people can reach out, we'll make sure to include those as well. Carlos, it has been awesome having you on. I can talk to you for hours and hours, but we'll leave that for another time. We don't get to meet each other the other week for a very short amount of time.

Carlos Polop:
Very, very, very short.

Joseph Carson:
Very short amount of time, but definitely I'm pretty sure we'll cross paths again in the near future, whether you're going to be at either Blackout or DEF CON or RSA or whatever events in the near future, we'll definitely make sure to catch up and spend some time together. But it's been awesome having you on the show. For me, it's a topic that I love talking about. It's one of my favorite things to do as I mentioned, and what you're doing in the community and the work that you do is amazing. It's fantastic. So please, whatever we can do to support you, we'll do what we can to keep it going. Any final things you would like to say to the audience before we finish up and wrap up for the day?

Carlos Polop:
No, man, I really appreciate the work and I completely agree the way to improve the cybersecurity is working together and what a best way to work together that's a medium pull request to HackTricks. So I invite everyone to do that. Now just as a side note, thank you very much for having me here. I definitely enjoyed as you know, the privilege escalation topic and it's always a pleasure to talk to you and I hope we'll be able to meet in person with a longer period of time.

Joseph Carson:
Yes. Absolutely. And yeah. Maybe normally because the problem is that when you're wearing mask as well it's hard, may as well have names or something on the mask. That's also makes it little bit easier to see who is who. But it's been awesome having you on. Many thanks for everything. And again, for the audience, definitely go, if you're looking to learn more, we'll make sure you get the links to the show notes. Definitely go check out Carlos's repo and again, tune in every two weeks for 401 Access Denied Podcast is really here to help share knowledge with you and introduce you to awesome and amazing people. So again, stay safe and thank you Carlos, for being an awesome guest in the show.

Carlos Polop:
Thank you. Thank you very much.