hpr-knowledge-base/hpr_transcripts/hpr3514.txt

Episode: 3514
Title: HPR3514: Hacking Stories: Soft Drink
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr3514/hpr3514.mp3
Transcribed: 2025-10-25 00:49:13

---

This is Hacker Public Radio Episode 3514 for the first ever 20th of January 2022.
Today's show is entitled Hacking Stories, Soft Drink, It Is Hosted by Operator and is
about 21 minutes long and carries an explicit flag.
The summary is, I talk about how all the penitor's story is.
Hello everyone and welcome to another episode of Hacker Public Radio with your host.
Today we're talking about stories, Hacker stories again. This one's again from Way far back.
A lot of these are way far back, so the order of events may not be right.
There might be a mix in the match between the two, but in general I can remember which
engagements aligned with which activities in general.
Anyone, this was about a big soft drink manufacturer or distributor, whatever,
and was with a new guy who was on our team. Pretty green, smart guy,
you know, really self-motivated and started getting into his own,
finding his own groove pretty quickly after one or two assessments.
So anyways, we get on site and usually we have a thing called a kind of a kickoff meeting.
So you get there, you get on site, maybe the managers with you, key, you know,
stakeholders within the meeting attend that first meeting and usually it's in the morning on the
first day of actual testing or maybe it's a day before if you're lucky.
But generally speaking, you just go there and you explain what your approach is and make
everybody comfortable, establish points of contact, if it's after hours, you know, maybe there's
some other moving parts to that assessment. In general, it's pretty standard stuff.
The key about this one is that I showed up on site, had my little USB
Ducky thing, which would give you a PowerShell payload.
Well, even things like Windows Defender and stuff like that.
Nowadays we'll pick all that up or any EDR tool will pick most of that up, the simple stuff.
But this was before kind of the heyday of been testing where you didn't have the role
your own thing. You just go and get heaven download something and it would work.
So anyways, I had this USB key that would give you a shell via physical access.
So somebody left their workstation unlocked, you plug the key in and you get a shell to wherever you
want. Now these were shells were set up internally. So I had a host on my laptop already plugged
into the network on like the local land or whatever because they don't have any protection against
monitoring, which means I'll quote back a little bit port monitoring basically prevents
someone from just arbitrarily plugging into the network. So what that said, it's generally you
don't see it at all. If you do see it, it's usually not implemented correctly. What should happen
is you should have a certificate for each host and that certificate should be validated when they
connect to the network. What ends up happening is most of the time it's a MAC or test filtering thing
where all you have to do is pretty much plug the device in, you want to clone, listen to the packets
for it to call out home and say, hey, I'm just connected to the internet. Here's my MAC address,
you know, server give me an IP address and the server says, oh, that's you, this is the guy and
puts you on the network. Well, if you have physical access, you're just going to physically plug in
the device that's supposed to be there and emulate that device. Now there's some small things you
can do within, like I think deep packet inspection and some other stuff outside of basic security
and MAC address filtering that you can kind of fingerprint and match that fingerprint to a device.
But in general, you don't see that either. You're going to haven't seen it well implemented.
So generally you can take a just desk phone, for example, and say, hey, I'm a desk phone and end up
on the network through MAC address filtering. So anyways, long story short, the idea is that you can,
you know, just plug in any device into the network and then you're good to go and you set up that
as a listening server to listen out for what they call beacons. So you set up a beacon and it could
be anything. It could be a piece of programmers snippet of one programming language or whatever,
and that that thing phones home and establishes a command and control CNC server or whatever.
Anyways, I'm going along with a way of kind of explaining how basic, you know, remote stuff works.
Anyways, this particular lady had gotten up from her desk to go to this kickoff meeting,
and while she was doing that, of course, I said, well, she's a good person to any.
Could have been anybody, could have been somebody else I walked by, their office with their screen,
but they didn't lock their screen. And a lot of the screen title idols are somewhere around 60 seconds.
And some of my payloads actually bypassed that by just keeping the system idle. So if I do
pop a shell on a box, they actually have to lock their physical workstation. It won't just unlock
automatically. It'll stay open. So even if I want to come back later, that little script runs
on the background to keep the server, the workstation live and presses the F 22 button every 59 seconds
to make sure that the system stays on. So even if they do go to the bathroom and think that they're
systems going to be locked in 60 seconds, it's not going to be looking to get back on there.
If I need a reestablished persistent or run some of their something as an escalated user,
and I don't have the rights, the correct rights. So anyway, she gets up, walks off, I drop my payload,
I get my shell. So before we even have a kickoff meeting, I've already got a shell on the box,
which is not generally, you know, it's kind of necessarily unfair. But with that said,
you know, someone like, it's not like she was going to walk her workstation because I was there
anyways, because she knew I was there. So anyways, before we even start testing, essentially,
I've got a shell via physical access, of course. With that, it's kind of funny. The other part is
I brought block set and I had been a little bit into lock sport just from a security standpoint,
identifying weak points in different engagements and saying, hey, you know, you have, I see a lot of
double doors that are for whatever reason, not secured. A lot of times it's multi-tenant
environments where they've leased out that area to a person. So they'll, a person or a group
of company. But you see it a lot more within institutions that have a multi-tenant environment.
And you also see it a lot more with like a double doors. So there'll be external doors, you know,
secure whatever if they got RFID they can't get in. But after that, you'll see a lot of times
you'll have big gaps in the doors where you can just almost take a finger in the door and unlock it.
In some cases, you know, you can do some other shenanigans to get the door door open. But a lot of
times the, you'll see these super loose doors where you can just shove something in the door,
credit card or piece of metal or whatever and then pop it in. So I had, I had looked around,
walked around a little bit and found kind of a maintenance closet or maintenance area.
And this place didn't have much in there, but it was a nice quiet place for us to do when
you kind of shenanigans if we wanted to do something that we didn't want anybody to physically
see us doing. But other than that, there wasn't anything of value in there. It's all a brief case and
it's a little like leather style briefcase and opened it up in there. It was a USB stick in there.
I said, oh, there might be something interesting on here. Of course, popped it in and there wasn't
anything interesting. I mean, I wouldn't have been surprised. Had there be something pretty cool
on there, but there wasn't. It was like maps to the to the building or something, which some
people would find sensitive. But generally speaking, like, you know, this isn't like the movies where
they download maps from the building and use that to like crawl in through the gutters or what do
you call it? The ventilation system from like an order reporter or whatever. It was a bond. Anyways,
so there's nothing, nothing, not much there. And meanwhile, the guy I'm with who's pretty green
smart kid. He seemed pretty shy at first, but eventually he kind of started opening up and he
was kind of freaking out and being like, oh, yeah, but you know, we're doing this thing. We're
doing that thing. And it's like, this is your job. You'll learn to get used to it. And it'll be
comfortable after a while. Just relax. Pretend like you belong there. Put yourself in their shoes
and just pretend that you're supposed to be there. That kind of helps. So we're doing some initial
testing and we've gotten some credentials at some point for a couple of credentials for something.
And we're using those credentials. So when you probably talked about this before, but if you
have access to a Windows box, back then a little bit less nowadays, you would be able to dump the
hashes. And being able to dump those hashes, you can take those hashes and pass them around to
other places without having the actual password. So when computers negotiate SMB V1 days,
which they're still SMB V1 everywhere, when you authenticate to another computer and Windows,
if you have that hash, you don't necessarily need the password to access that system. So if you're
able to dump the hashes of that system, you can potentially, in most cases, use those hashes,
especially if they're the same local administrator password. You can use those hashes somewhere else.
So there's a thing within Windows called laps LAPS local administrator password service.
And that will kind of help with that stuff. It'll rotate out the local admin password based on
some magic. And it will keep you from having everybody having the same local admin password.
So anyways, when you don't see laps, you know that you can do a thing called password spraying.
So traditionally, if I were to try to log in 10,000 times with your account,
it's going to lock it out after the first three, six attempts, whatever. With password spraying,
you're essentially taking one password and using that against thousands of accounts. So the idea
is you won't be detected by simple password blocking mechanism. So if there's 50,000 accounts,
you try the password on all 50,000 accounts, and you try the next password on all 50,000 accounts,
you'll never get locked out because, you know, the timeout for those is between each password is
going to be so human for our between. It'll only show that you're trying my password every minute
or two minutes or whatever. So that's what you traditionally would do during these assessments.
When you don't have a lot of time, you just get credentials, you spray, and you pivot,
get credentials, you spray, and you pivot until you get local administrator. And then from that,
you want to get doming in minutes. So anyways, I'm using medicine. This is way back. And you can use
that to password spray a bunch of accounts at once. So he's relatively green to that piece of software.
And I'm kind of kind of have doing my thing. I'm kind of doing two things at once. And I'm kind
of trying to help him. So I'm kind of doing three things at once. I'm kind of keeping an eye on him,
seeing if he has any questions, trying to make do nine notes, and trying to do scans and performing
my testing all kind of at the same time, which in hindsight, that should be something that should
be done kind of one at a time. Whereas I do my work, and then I maybe pause for some brief moment,
and then shoulder serve him for a little while, and show him how to do certain things, and then
go from there. You kind of don't want to let someone just go willingly on corporate network.
And not shoulder served him at least the first few times to let them know, okay, here's what
you need to be aware of. Here's what you need to not do. Here's the five things that you shouldn't do
outside of just standard scoping limitations, but just for for lack of better term, just
etiquette within networks nowadays. So I have him set up this password spring tool,
and unfortunately I set it up incorrectly where it would do the opposite. It was kind of spray
those accounts with a bunch of passwords, and of course the wrong passwords. So not only was it
a bunch of accounts, it was a wrong password, which will trigger a logout. So what ended up
happening is I don't know how it happened. I think maybe I wasn't setting up the tool right or
something, and it went and locked out every single user within Active Directory. Now I'll link
a script that basically fixes all this for you in the show notes. Hopefully I still have it.
I may not have it, but it basically downloads the admin module for Windows automatically,
and then it will perform a check against Active Directory and say, okay, you know, with your credentials,
I'm going to try to unlock every single account out with one simple three or four line script
and power. So, you know, we're in the middle of this. We don't realize anything bad is happening,
and in the background, we're in a different room. Sometimes you're in a cubicle area where you can
literally hear things failing, and you start hearing about people complaining about being able to log in
or whatever, you know, it's happened a handful of times, but one of the times that it did happen
is I was around cubicles, and I could hear people literally talking about, you know, getting locked out
and things like that. So, it's not a fun thing happened because, you know, you're obviously
know you're impacting people in real world. So, anyways, some time goes by, and the main security
guy, our lead security guy on the client side, comes in and he proceeds to pop his head in and say,
you know, look, I don't know what you guys are doing, you know, but all our accounts are locked out,
and of course I tell him to stop immediately, and he seems kind of perplexed and is confused as to,
you know, why could this have happened, why could a single person essentially halt our entire
company because, you know, getting locked out wouldn't necessarily think of play as a denial of
service, but essentially that's what it is availability, you're attacking the availability of a
platform, and that is authentication. So, if a particular user were to be really mean,
they would get a list of all your external login names. Now, that's why a lot of companies,
their email addresses are different than their login because what happens and can happen is that
if somebody wants to do a denial of service against your company, they can basically
brute force every single user name with a bunch of passwords and block everyone's account out
at the entire company if they have a company username list or an email list that's tied to that,
that username. So, a lot of times within bigger enterprises you'll have your email address and your
username will be different than your email address on purpose because people who used to use their
email address as their username or, you know, at whatever.com, everything before that, and we started
having instances where availability was impacted because some clown would get a dump of all the
user names at your company and then they would proceed to, you know, and try to pack into something
and lock everybody's account out or lock a large swath of accounts out. So, that said, you know,
he comes in, like, I was locking everything out. I kind of backtrack and, you know, I take full
responsibility for anything like that and I say, you know, he's green. I kind of told him what to do.
It's all on me, you know, don't worry. I know, you know, this is one that made a mistake. I wasn't
making sure that, you know, we were doing the right things and he took a very well, you know,
he said, well, this is actually a good finding because, you know, if one user can lock out all
of our accounts and essentially stop the business, then that means that we should probably look at
fixing that. And at some point in time, I think this was before the massive amount of unlocking,
locking out accounts. We had, or I had had a session with a specific computer and I told the
security guy, I said, you know, I know you use, I don't know if they were using something
along the lines with snort or whatever one of those fire watch or fire or something or other or
one of those network based deals. Anyways, it looks at network traffic and maybe it has an
endpoint piece on it, but I don't think this had an endpoint. It was a network tool that would tell
you, you know, if there's any shells going on, things like that. I actually think it was maybe
carbon black or or something like that where it actually had endpoint visibility. You could see
what programs were running. So I told him to bring his tool up and say, you know, hey,
here's your kind of, I guess it was only an EDR, but it was a endpoint visibility security
tool. So hey, bring up your, your security thing and here's the host name and tell me make sure
that we can't, that you can't see my shell. And he says, he's a can't. Oh, yes, make sure that
you can't see my shell. I want to make sure that my shell is hidden from this security tool. And
of course, you know, it was plain Jane, you know, regular, medispoint reverse payload thing. So,
you know, he brings up the host name, looks at the thing, looks at the tree view and like,
no, I don't see anything out of the ordinary here. I'm like, oh, hey, good. Well, you know, that's
one of the findings I can take ahead and say, you know, you guys, you know, need to be aware of that
just because you think you have visibility into something and there's some missing pieces there.
But this was kind of way before EDR and injecting process injection and all that stuff was being
tracked and monitored. So you just ended up with like, no pad. And it's like, okay, they're running
no pad, but why did no pad all of a sudden spawn, you know, a command shell. So there wasn't that,
there wasn't that visibility into kind of pivoting aspects type of thing. So we ended up getting
from there. It was, you know, local admin credentials. I'm sure that we use somewhere else.
Usually it's a service account for monitoring of all things. So a lot of servers, Windows servers,
especially will have some kind of monitoring access aspect of it, a CCM, whatever. And what can
happen sometimes is these systems can be taken over. Those local credentials can be used to, for
whatever reason, those local, our local credentials are cached or they're the same on every system.
And then you can pivot to other systems. So you just pivot dump credentials, pivot dump
credentials. And then eventually you find domain administrator or an account that has access to
the domain admin computer. And then you can pivot from there and create your own domain admin.
I will say if you do have domain AD, there's a bunch of basic simple stuff that will help slow
that process down. And I don't remember the website, but it was like 80security.org. It's like
one guy. And he's like the only handful of guys that actually, you know, understands AD from
a security standpoint. I want to say it's not 80security.org. It's some other, so I think it's
pretty much some other guy. Anyways, it's like active directory, something or other guy. And
anyways, there's some guides in there that will help slow down these types of attacks. So if
somebody does get access to a domain administrator, they can't just arbitrarily create a domain admin
account. They actually have to have credentials to the domain add domain controller. Then they have
to pivot to that domain controller. And then they can add credential to that account. So if they can't
get to the domain controller because of firewalling or whatever, then they have a domain admin
account, but they can't create their own domain admin account because that user is not, you know,
set up to be able to create account from without having been on the actual domain domain server,
whatever. Anyways, there's a bit of a tangent, but there's there's a lot of active directory
security guides out there. There's a million things you can do so much with just group policy
objects and app white listing within Windows. And people don't really realize that if you really
understand AD, you don't really need a whole lot of tools. If you understand group policy objects
and security around all of them, you can create basic stuff like word pad and Microsoft Word
shouldn't be dropping binaries or executing executables. Like that's just not something that
is supposed to happen. So like if, you know, when Word or Excel, all of a sudden runs an executable,
that's not something you want. And you can turn that on within sight of Word and Microsoft
products to say, okay, just basic stuff. And within AD, AD security and group policy objects,
there's so many things you can turn on that will not impact business that will help with that space.
Anything's. I'll see if I can remember to try to find the link and put it in the show notes for
that. Let's see what else we got here. Other than that, I was on my way out the door. And generally
the last day, I'll try to clean up my tracks and make sure that whatever I left behind, I cleaned
up after. So I'm not leaving like shells and users and accounts all over the place. So I'll usually
have like a little note that I'll print out or usually just write as best I can because my handwriting
is terrible. I would write, you know, here's the domain admin account proving that I, you know, got
domain admin, blah, blah, blah. If you want to remove it on my way out the door, feel free. You know,
we have our screenshots and all that stuff. So as, as I'm kind of at the door, I hear a guy talking
about Plex, which back then Plex was still pretty, pretty new. It's a kind of build your own Tivo.
If you remember Tivo days, it's essentially like build your own streaming media service and you can
share between box to box. So if I have a server, you have a server, we can share each other server
and see each other's content and all that. So when I log in, I can see all the people that I've shared
my server with. So anyways, as I'm passing by, you're, you're, I mentioned Plex and I kind of peak my
head over and I say, oh, here's my email address. If you want to whatever and still to this day, I mean,
this is, I don't know, 15 years later, 10 years later, I have an account still with his Plex account.
He doesn't have a ton of stuff on there, you know, I'll look in there and run it around, see if
anything interesting. But it's kind of a good, interesting story. It's kind of, kind of, I want
the highway out and establish a relationship sort of that I'd still utilize to this day.
Anyways, that's pretty much it. The only other thing is I say that was free, free of this
soft drink that was free, but a lot of them had caffeine in them. And I eventually found one
that I thought didn't have caffeine in it. So I'm sitting here drinking a drink in it and I realized
I've drive had like three cans of it that it's not just a, it's not just a cocoa or coffee drink
or whatever. It's like not caffeinated or whatever it had like caffeine inside of it too. Anyway,
so I ended up making things almost as bad as drinking a bunch of sodas. That's pretty much it
for this one. And hopefully we'll have more coming down the pipe. I've got plenty of these that
are more recent, but I'm trying to get the old ones out of the way so that I can, you know,
so they don't start leaving my brain. Anyways, have a good one, dig it easy.
You've been listening to Hecker Public Radio at HeckerPublicRadio.org. Today's show was
contributed by an HBR listener like yourself. If you ever thought of recording a podcast,
then click on our contribute link to find out how easy it really is. Hosting for HBR is kindly
provided by an honesthost.com, the internet archive and our sync.net. Unless otherwise stated,
today's show is released under a creative comments,
attribution, share-like, slid-as-o-licence.