1
00:00:00,000 --> 00:00:05,200
Top of the hour, it's 5 p.m. in beautiful Las Vegas, Nevada, and at DEF CON 25.

2
00:00:05,900 --> 00:00:08,480
How is everyone? Tired?

3
00:00:11,000 --> 00:00:14,860
Yeah, I'm just going to take 10 minutes to ramble.

4
00:00:16,040 --> 00:00:21,460
Just going to put on open mic, I guess an open mic for the next 10 minutes.

5
00:00:22,940 --> 00:00:28,980
So, thank you so much for being with us here at the Packet Hacking Village.

6
00:00:30,480 --> 00:00:31,260
All day.

7
00:00:31,620 --> 00:00:37,360
Let me tell you, you really, really made this first day, actually, I'm feeling really amped up.

8
00:00:37,540 --> 00:00:44,420
I mean, seeing the crowd grow, you know, here throughout the whole day has been very, very welcoming.

9
00:00:44,620 --> 00:00:46,640
It's been awesome. It's been just awesome to see.

10
00:00:46,920 --> 00:00:48,700
Thank you so much for all your support.

11
00:00:49,300 --> 00:00:53,920
So, I just want to give you a, before, you know, before Peter comes on stage,

12
00:00:54,400 --> 00:00:59,780
I just want to give everyone a little preview for, I just want to give everyone a couple of notes.

13
00:01:01,100 --> 00:01:04,600
We have one more talk left for tonight.

14
00:01:05,320 --> 00:01:06,880
That starts at 6.10.

15
00:01:06,980 --> 00:01:08,460
It will be Cheryl Bezwas.

16
00:01:09,300 --> 00:01:13,060
She's with one of the big four, and she'll talk about Threat Intel for all.

17
00:01:13,220 --> 00:01:15,860
There's more than your data that meets the eye.

18
00:01:17,320 --> 00:01:21,160
So, let's talk about tomorrow, how that works.

19
00:01:21,420 --> 00:01:24,280
So, tomorrow we have a full slate of talk.

20
00:01:24,880 --> 00:01:29,360
In fact, we have, yeah, we have a full slate of talk tomorrow starting at 10.10.

21
00:01:30,000 --> 00:01:30,960
In the morning.

22
00:01:31,300 --> 00:01:35,040
And so, the first talk we'll have is Making Your Own Gadget.

23
00:01:35,040 --> 00:01:46,160
Making Your Own 802.11ac Monitoring Hacker Gadget by, I think, SecurityTube and the actual author of Aircrack.

24
00:01:48,120 --> 00:01:54,340
At 11, there's going to be a talk on the black art of wireless post-exploitation by Gabriel Ryan.

25
00:01:55,280 --> 00:01:57,120
12.10 will be very interesting.

26
00:01:57,520 --> 00:01:59,760
It will be a talk on, you know.

27
00:02:00,000 --> 00:02:05,400
War Stories on Fortune 100 InfoStack on a State Budget by Eric Capuano.

28
00:02:05,680 --> 00:02:12,400
And he's going to talk about what it's like to work for, like, a big, you know, work doing InfoStack for the state of Texas.

29
00:02:13,480 --> 00:02:15,200
At 1 o'clock, Yaldoc.

30
00:02:15,380 --> 00:02:19,500
Gita Ziavari will talk about large-scale data mining for Threat Intelligence.

31
00:02:21,060 --> 00:02:29,920
And after that, we have another talk by CloudFlare on the past, present, and future of high-speed packet filtering by Gil Biotel.

32
00:02:30,000 --> 00:02:34,160
We have a talk on Visual Network and File Forensics.

33
00:02:34,780 --> 00:02:37,720
Modern Day Covert's TCP.

34
00:02:39,200 --> 00:02:44,200
We have one on, you know, deceiving domain admin hunters.

35
00:02:45,740 --> 00:02:50,080
And we have another talk then followed by another one on hunting down domain admins.

36
00:02:52,440 --> 00:02:55,460
The late talks get very interesting.

37
00:02:55,660 --> 00:02:59,680
So, at 17.40, we have Megan Rohde who will talk about strengthening.

38
00:03:00,000 --> 00:03:04,020
A SecOps team by leveraging neurodiversity.

39
00:03:04,360 --> 00:03:05,920
That is going to be pretty cool.

40
00:03:06,300 --> 00:03:10,720
And last, we have Sam Bone who will talk about passwords on a phone.

41
00:03:11,480 --> 00:03:13,320
I think that they messed it up.

42
00:03:13,380 --> 00:03:14,900
They messed up the typos here.

43
00:03:15,320 --> 00:03:15,880
Okay.

44
00:03:16,260 --> 00:03:18,560
So, we have a full slate of talks tomorrow.

45
00:03:19,240 --> 00:03:22,420
Just want to remind you for everyone here.

46
00:03:22,720 --> 00:03:28,060
All the talks for the speaker workshop at the Packet Hacking Village.

47
00:03:28,520 --> 00:03:29,660
Is that all?

48
00:03:30,000 --> 00:03:31,820
All the talks are recorded.

49
00:03:32,100 --> 00:03:39,220
They will be made available on video along with the, at the same time when the DEF CON videos are released on YouTube.

50
00:03:39,740 --> 00:03:41,460
So, that would be like two to three months.

51
00:03:42,340 --> 00:03:43,920
So, what about the slides?

52
00:03:44,640 --> 00:03:46,100
That actually comes a lot quicker.

53
00:03:46,300 --> 00:03:55,560
When I go home, within the next two weeks, a good chunk of the slides will be posted on the Wall of Sheep website at wallofsheep.com.

54
00:03:55,820 --> 00:03:59,320
So, the video, the estimated time, two to three months.

55
00:03:59,320 --> 00:03:59,960
Two to three months.

56
00:04:00,180 --> 00:04:03,960
And then the presentation slide, two to three, two weeks.

57
00:04:04,100 --> 00:04:07,600
Within the two weeks that we go home from Las Vegas.

58
00:04:08,240 --> 00:04:08,680
Okay.

59
00:04:09,740 --> 00:04:14,180
So, with that said, the next thing is, I'm going to take a few minutes.

60
00:04:14,540 --> 00:04:14,980
Okay.

61
00:04:15,000 --> 00:04:15,680
So, it's 5.04.

62
00:04:15,800 --> 00:04:17,200
I've got a few more minutes to ramble.

63
00:04:19,100 --> 00:04:20,280
So, it is 5 o'clock.

64
00:04:23,200 --> 00:04:23,640
No.

65
00:04:24,660 --> 00:04:25,400
Stupid phone.

66
00:04:28,200 --> 00:04:28,800
You know.

67
00:04:28,800 --> 00:04:39,740
I do want to take this time and opportunity right now, because if you take a look around, and I hope you, I hope for all of you here that the Packet Hacking Village have been a very pleasant experience for all of you here.

68
00:04:39,900 --> 00:04:44,860
I hope that you've really, really thoroughly taken advantage of what we've offered in terms of learning opportunities here.

69
00:04:46,500 --> 00:04:51,020
If you take a look around, if you take a look around, I mean, none of this stuff comes cheap.

70
00:04:51,120 --> 00:04:55,320
I mean, the posters, the banners, and all that stuff, the t-shirts.

71
00:04:56,000 --> 00:04:57,740
I want to give a very, very...

72
00:04:58,800 --> 00:05:02,380
You know, thank you to our sponsors at DEF CON 25 this year.

73
00:05:02,600 --> 00:05:04,300
Wallace Sheep Title Sponsor, Splunk.

74
00:05:05,200 --> 00:05:08,120
Packet Detective Sponsor, Fidelis Cyber Security.

75
00:05:09,020 --> 00:05:11,940
Capture the Packet Title Sponsor, Packet Sled.

76
00:05:12,160 --> 00:05:14,900
Capture the Packet Platinum Sponsor, Talos.

77
00:05:15,100 --> 00:05:17,220
Sheep City Title Sponsor, Dark Matter.

78
00:05:17,540 --> 00:05:20,120
Sheep City Sponsor, 360.cn.

79
00:05:20,320 --> 00:05:28,780
Again, we're also looking for people who are no Mandarin, because we have a whole bunch of nice devices donated from 360.cn.

80
00:05:28,800 --> 00:05:33,020
That is available for you to break, but we can't rip it.

81
00:05:33,160 --> 00:05:34,000
I can't read Mandarin.

82
00:05:34,220 --> 00:05:35,280
I can't read Mandarin.

83
00:05:35,620 --> 00:05:38,680
And HoneyTouch Title Sponsor, 802 Secure.

84
00:05:39,260 --> 00:05:46,920
Okay, we want to thank you, and most importantly, thank you, each and every one of you, for spending your today here at the Packet Hacking Village.

85
00:05:47,780 --> 00:05:52,180
One more thing, and I guess this is another good time to do so.

86
00:05:52,500 --> 00:05:58,000
Another friendly reminder is a public service announcement before I introduce Peter.

87
00:05:58,140 --> 00:05:58,680
Can you all hear?

88
00:05:58,800 --> 00:05:59,360
Me in the back.

89
00:05:59,560 --> 00:06:00,360
Is this good?

90
00:06:00,640 --> 00:06:01,560
Is this good?

91
00:06:01,680 --> 00:06:01,820
Okay.

92
00:06:02,120 --> 00:06:03,820
So I want to give a public service.

93
00:06:04,000 --> 00:06:04,200
Whoa.

94
00:06:06,300 --> 00:06:07,260
Oh, those are yours.

95
00:06:07,520 --> 00:06:07,600
Oh.

96
00:06:07,800 --> 00:06:08,920
You don't know I'm there?

97
00:06:09,600 --> 00:06:10,120
Cool.

98
00:06:10,600 --> 00:06:20,300
So before I introduce Peter, I want to give a public service announcement here at the Packet Hacking Village.

99
00:06:20,440 --> 00:06:28,500
And that's on an issue that is a serious problem in cybersecurity and also in tech.

100
00:06:28,540 --> 00:06:28,780
And that's...

101
00:06:31,080 --> 00:06:32,260
It's a no-no.

102
00:06:32,500 --> 00:06:33,340
Don't go there.

103
00:06:33,500 --> 00:06:34,480
Don't do anything stupid.

104
00:06:35,180 --> 00:06:40,300
In fact, sadly, we also had a few volunteers that were a victim of it last year.

105
00:06:40,460 --> 00:06:45,400
So, of course, this is something that's been near and dear to us, that we take very seriously.

106
00:06:45,600 --> 00:06:46,620
It's not tolerated.

107
00:06:46,840 --> 00:06:47,640
Absolute no-no.

108
00:06:47,800 --> 00:06:48,600
Don't go there.

109
00:06:48,760 --> 00:06:57,960
And as I tell every of my students on the second day of my class, you know, you know, don't...

110
00:06:58,800 --> 00:07:06,300
Give the community and the industry and also the field another more black eyes and a more bad rap.

111
00:07:06,600 --> 00:07:07,000
Okay?

112
00:07:07,160 --> 00:07:07,980
It's a no-no.

113
00:07:08,120 --> 00:07:09,580
It's an absolute no-no.

114
00:07:09,860 --> 00:07:16,420
So, with that said, now it is my pleasure to introduce to you Peter Wane.

115
00:07:18,380 --> 00:07:19,000
Hello.

116
00:07:19,000 --> 00:07:19,060
Hello.

117
00:07:29,680 --> 00:07:33,280
I see a lot of faces that I know that I wish weren't here.

118
00:07:35,560 --> 00:07:38,300
I'm going to warn you right now, this is not going to be great.

119
00:07:39,340 --> 00:07:44,820
But anyway, so to give you a brief primer of the way I present things normally, I tell a lot of bad jokes.

120
00:07:45,120 --> 00:07:48,740
They're an attempt to hide the lack of quality that I have in my slides.

121
00:07:49,420 --> 00:07:50,940
And then hopefully you will laugh at them.

122
00:07:51,860 --> 00:07:53,120
But in general, we're going to...

123
00:07:53,120 --> 00:07:58,640
Today I'm going to walk you through different post-compromise techniques that attackers use in AWS.

124
00:07:58,800 --> 00:08:00,340
In order to hide themselves and such.

125
00:08:00,840 --> 00:08:02,240
And hopefully that sounds good to you.

126
00:08:06,240 --> 00:08:06,880
Thank you.

127
00:08:09,080 --> 00:08:10,180
So, I'm Peter.

128
00:08:10,840 --> 00:08:12,940
And I'm a security researcher at AlienVol.

129
00:08:13,400 --> 00:08:18,860
I like cocktails and I like really like weird funky wine where you can't tell if it's bad or is it like really, really good.

130
00:08:19,620 --> 00:08:27,240
I'm from Texas and if you would like to follow me on Twitter where I talk very little about funky wine and even less about security, that's my handle down at the bottom.

131
00:08:29,360 --> 00:08:31,640
So, we're going to give you a brief intro to AWS.

132
00:08:32,080 --> 00:08:35,320
Can I get a brief show of hands of anyone who doesn't know what AWS is?

133
00:08:37,040 --> 00:08:38,660
Who knows what AWS is?

134
00:08:39,800 --> 00:08:40,560
Thank God.

135
00:08:43,520 --> 00:08:54,640
We're going to talk about a few common infection vectors, hiding techniques, the persistence techniques, and then some hardening tips that hopefully you can take back to your company and make sure that you don't get hacked like this.

136
00:08:57,680 --> 00:08:58,680
Someone just followed.

137
00:08:58,800 --> 00:08:58,820
Help me.

138
00:09:01,420 --> 00:09:02,220
Y'all are fast.

139
00:09:04,340 --> 00:09:05,700
So, what is AWS?

140
00:09:06,820 --> 00:09:10,180
So, the first question is who is Amazon and what are their web services?

141
00:09:10,460 --> 00:09:16,200
For the articles I've been seeing in Forbes, a couple years ago, Amazon only sold books.

142
00:09:17,320 --> 00:09:24,060
But nowadays, they seem to be like one of the forefront leaders in cloud computing.

143
00:09:24,180 --> 00:09:28,240
And everyone from like two, three person mom and pops to like major.

144
00:09:28,800 --> 00:09:28,820
And that's been right there.

145
00:09:28,820 --> 00:09:32,260
So, the first question is what's AWS and basically the way that AWS is, right now, most of the companies are storing everything inside AWS.

146
00:09:32,700 --> 00:09:42,600
They have the servers inside AWS and it becomes very lucrative for attackers to leverage this deployment in order to make money, get credentials, what have you.

147
00:09:42,900 --> 00:09:44,640
And the question is why should you care?

148
00:09:46,120 --> 00:09:49,600
How many people here host things inside AWS for the company?

149
00:09:51,180 --> 00:09:51,800
Thank you.

150
00:09:51,840 --> 00:09:52,960
I thought it was only one hand.

151
00:09:53,300 --> 00:09:54,820
It was going to be very poor talk.

152
00:09:54,820 --> 00:10:00,420
but we really should care because these days inside AWS as you lock down platforms more and

153
00:10:00,420 --> 00:10:06,060
more and more like for example I can only access your application on port 80 on 443 and most

154
00:10:06,060 --> 00:10:10,660
attackers aren't going to spend like 6 months fuzzing your platform to see what race conditions

155
00:10:10,660 --> 00:10:16,500
that you have inside to get in there. But if I happen to leverage some credentials I find at

156
00:10:16,500 --> 00:10:21,640
AWS I have the ability to back door everything from the application itself to your AMIs to

157
00:10:21,640 --> 00:10:28,320
whatever to what we're going to see in a little bit. So these are very common compromised

158
00:10:28,320 --> 00:10:34,860
vectors inside AWS. Number one is infected machines. As more and more people go to work

159
00:10:34,860 --> 00:10:41,000
remote and BYOD infected machines are always a problem even if they don't get infected on your

160
00:10:41,000 --> 00:10:45,800
corporate network. People take their laptops home, they bring them back in, they're infected and

161
00:10:45,800 --> 00:10:51,520
then from there they can infect the corporate network. And then second is phishing. As much as

162
00:10:51,640 --> 00:10:56,760
we try to train users phishing has always been and will always be a problem. We constantly read

163
00:10:56,760 --> 00:11:03,800
articles about someone pretending to be a CEO that you know has like one A off or one capital or

164
00:11:03,800 --> 00:11:12,360
what have you saying wire me $500,000 and someone in finance is like absolutely. You're down

165
00:11:12,360 --> 00:11:16,000
the hallway from me. I'm not going to ask you about this. I'm just going to wire it immediately.

166
00:11:17,020 --> 00:11:21,340
And then credential leakage. Credential leakage is a huge one. So there's popular

167
00:11:21,340 --> 00:11:25,700
applications such as Git rob that scrape through GitHub. There's other applications that scrape

168
00:11:25,700 --> 00:11:30,440
through big bucket or paste bin or what have you because too many people hard code credentials and

169
00:11:30,440 --> 00:11:36,440
then push them to paste bin or GitHub and ask questions about them. So from here you can find

170
00:11:36,440 --> 00:11:43,900
anything from SSH keys to secret tokens to what have you that you need to log into AWS. And I'm

171
00:11:43,900 --> 00:11:47,640
going to go ahead and say a lot of companies are cheap and people share credentials. So if you own

172
00:11:47,640 --> 00:11:51,320
that one set of credentials you own the entire corporate infrastructure. So this is a great way to

173
00:11:51,320 --> 00:11:54,620
do that. I'm going to assume none of you in here share credentials at your company because that's

174
00:11:54,620 --> 00:12:03,240
bad security, right? Y'all can say no. Alright and then the last one is social engineering. So I'm

175
00:12:03,240 --> 00:12:06,940
sure some of you in here are red teamers and you know you can go through this whole thing about

176
00:12:06,940 --> 00:12:11,380
like you know trying to get people's passwords, trying to use mini cats like scrape things out of

177
00:12:11,380 --> 00:12:16,400
memory or you can just call the front desk and say that you're a new user and you would like your

178
00:12:16,400 --> 00:12:21,140
password reset and generally they'll reset your password. This can also be another common

179
00:12:21,320 --> 00:12:29,540
infection vector into AWS. So besides user-based infection vectors there's also service-based. So

180
00:12:29,540 --> 00:12:35,460
service-based I want to say is because it's built in tools in AWS that can just be abused and

181
00:12:35,460 --> 00:12:40,720
leveraged in a way that they didn't originally intend. A major one is third-party monitoring

182
00:12:40,720 --> 00:12:47,840
services such as let's say a data dog or what have you for monitoring the uptime inside AWS. You

183
00:12:47,840 --> 00:12:51,300
can make your application and your corporate network as secure as you want but if one of your

184
00:12:51,300 --> 00:12:55,880
of these third parties get compromised and they have a token to log into your environment,

185
00:12:56,040 --> 00:13:01,320
whether it be the OAuth, what have you, then you effectively lost the battle. The second

186
00:13:01,320 --> 00:13:09,660
one is metadata leakage. The EC2 has a fair amount of metadata, so if you go to EC2 and

187
00:13:09,660 --> 00:13:17,240
select an object here. I seem to have put someone to sleep already. I like how everyone

188
00:13:17,240 --> 00:13:23,540
turned and saw him immediately. You can look at the AMI, you'll see the AMI version, you'll see

189
00:13:23,540 --> 00:13:29,040
the kernel, you'll see the region, and all this metadata is available through a web server that's

190
00:13:29,040 --> 00:13:35,180
only normally available through that instance itself, but if you have weak VPC separation or

191
00:13:35,180 --> 00:13:40,880
segmentation through your network, it's possible to query from one foothold that I had over here to

192
00:13:40,880 --> 00:13:46,520
query over here. And while this metadata may not seem important, it can, number one, tell me

193
00:13:46,520 --> 00:13:47,220
which regions you have. Number two, it can tell you which regions you have. Number three, it can

194
00:13:47,240 --> 00:13:50,720
tell you which hostings, and it can tell me common naming schemes you use. It can tell me

195
00:13:50,720 --> 00:13:55,780
different things where I can use that phishing that we talked about before and that social

196
00:13:55,780 --> 00:14:02,500
engineering to get people to leverage to get more data. There's also AMI poisoning. Once I have

197
00:14:02,500 --> 00:14:07,320
those set of credentials, it may be very difficult for me to hack your application in

198
00:14:07,320 --> 00:14:12,780
particular. Let's say you're just one of the best secure coders that's ever existed ever. But

199
00:14:12,780 --> 00:14:16,220
I back to your AMI and just add a nice account that

200
00:14:16,220 --> 00:14:21,720
has a cron job that sends me all the credentials I've logged through back to my web server. It

201
00:14:21,720 --> 00:14:30,260
doesn't matter how secure your web application is, does it? You can say no. Thank you. There you go.

202
00:14:30,340 --> 00:14:33,860
Like I said, we have to be interactive. We have to feel each other. It's going to make things go

203
00:14:33,860 --> 00:14:41,120
much more smoothly. And then there's instance profiles. Instance profiles, has anyone used them

204
00:14:41,120 --> 00:14:46,200
before? Let's see how in depth they go. All right. Instance profiles are defined by the

205
00:14:46,200 --> 00:14:51,920
AWS, usually by the architect who is like making everything. It determines which permissions are

206
00:14:51,920 --> 00:14:57,680
going to be available through the EC2 instances in the profile. For example, you'll be able to

207
00:14:57,680 --> 00:15:04,180
create an instance with a profile that has SQS for hitting whatever databases. Those permissions

208
00:15:04,180 --> 00:15:09,040
will usually just allow people to hit the API, but once created, that instance profile is

209
00:15:09,040 --> 00:15:13,260
associated with EC2 instance or a launch configuration, and when the instances are started,

210
00:15:13,320 --> 00:15:16,180
AWS creates a unique set that allows people to hit the API. It's a really simple process. The

211
00:15:16,180 --> 00:15:20,100
of access keys, a secret key and a security token, which makes them available through

212
00:15:20,100 --> 00:15:25,120
the instance, through that metadata that I talked about earlier. So that metadata that

213
00:15:25,120 --> 00:15:29,240
you'll query, it lists, let's say, for example, for layman's terms, usernames and

214
00:15:29,240 --> 00:15:34,380
passwords that are able to log in. And one of the lowest pieces of low-hanging fruit is

215
00:15:34,380 --> 00:15:40,060
this public EBS snapshots. So these snapshots are just like a snapshot of a virtual machine.

216
00:15:40,320 --> 00:15:46,080
But for some reason, some companies choose to make these snapshots public. Whether

217
00:15:46,080 --> 00:15:49,340
they tell themselves, I'm only going to make it public for five minutes so I can download it

218
00:15:49,340 --> 00:15:52,920
onto my local machine or I'm going to send it to someone, what have you, and then they forget

219
00:15:52,920 --> 00:15:58,340
to revoke it. So going through these snapshots, you can find anything from SSH keys to hard

220
00:15:58,340 --> 00:16:02,400
coded credentials to those secret keys that we talked about earlier to any sort of private

221
00:16:02,400 --> 00:16:07,780
data. And if you don't believe this, you can just go on to EC2 honestly and go to EBS and

222
00:16:07,780 --> 00:16:15,240
just select public, go through, download some images and see what you find. And that leads us

223
00:16:15,240 --> 00:16:16,060
to different ways of tapping.

224
00:16:16,060 --> 00:16:22,820
Attackers can hide in AWS. So number one is going to be CloudTrail. CloudTrail, if made

225
00:16:22,820 --> 00:16:27,560
properly, audits everything that happens inside Amazon. Everything from adding users,

226
00:16:27,880 --> 00:16:33,860
everything from monitoring their keys to everything. So one of the first loud things an

227
00:16:33,860 --> 00:16:39,180
attacker would do when they go through is delete all the logs. But more than likely, if someone

228
00:16:39,180 --> 00:16:46,040
like Eddie Lee in the back deletes all the logs, we'll notice. Bless you. Which leads us to the

229
00:16:46,060 --> 00:16:49,920
S3 trail. This is something that would be slightly more sneaky. It's just stopping logging. So

230
00:16:49,920 --> 00:16:54,760
instead of deleting all the logs, you still have your logs. I just stop. And everything I go,

231
00:16:54,880 --> 00:16:59,820
going forward, will be on logs. So you're going to have to audit every single profile, every

232
00:16:59,820 --> 00:17:08,440
single AMI to see if I've modified anything. And then that brings us to the S3 trail. So a lot of

233
00:17:08,440 --> 00:17:12,140
people push their logs into the S3 buckets because, you know, it's very simple to set up

234
00:17:12,140 --> 00:17:16,000
inside Amazon. So if I don't want to delete your logs and I don't want to stop logging because I

235
00:17:16,060 --> 00:17:20,440
assume you have correlation rules set up for that, I can modify the log rotation policy. So

236
00:17:20,440 --> 00:17:28,900
normally you would, normally you would rotate the logs about once a week, tar them, push them to an

237
00:17:28,900 --> 00:17:34,340
off-site storage, and I can modify that to every one minute. But then I can also change the

238
00:17:34,340 --> 00:17:39,620
location of where those logs write. And something you'll find out is there's also public S3

239
00:17:39,620 --> 00:17:45,100
buckets. So I can change that from your corporate network to push to someone else's. So you don't

240
00:17:45,100 --> 00:17:46,040
notice anything about your logs. So I can modify that to every one minute. But then I can also change

241
00:17:46,060 --> 00:17:48,260
the location of where those logs stop logging because you no longer have access to those logs.

242
00:17:49,000 --> 00:17:54,640
And one of my favorite sneaky things to do that I've seen is the key management service. So

243
00:17:54,640 --> 00:18:00,080
inside this key management service, your logs will keep writing. They will keep going to your own

244
00:18:00,080 --> 00:18:06,620
S3 bucket or wherever drop box that you had to put it to. But I can instruct CloudTrail to use

245
00:18:06,620 --> 00:18:11,980
this particular private key to encrypt everything and then destroy it. So you won't have access to

246
00:18:11,980 --> 00:18:16,040
your logs. I will. But as the attacker, I don't really care. . . . . . . . . . . . . . . . . .

247
00:18:17,000 --> 00:18:25,860
. . . Well, leaves us over to persistence. One easy way of maintaining persistence inside

248
00:18:25,860 --> 00:18:32,160
AWS is just creating a new user. It's cloud. You'll see it more than likely. If you're a small

249
00:18:32,160 --> 00:18:36,660
company, you'll definitely notice someone adding 1 or 2 users but if you're a large conglomeration

250
00:18:36,660 --> 00:18:43,400
where users are added and deleted every single day, that might just be more noise. Particularly

251
00:18:43,400 --> 00:18:46,020
sneaky thing to do when you're creating a new user. Instead ofуб representing that new user

252
00:18:46,020 --> 00:18:51,120
creating let's say Jonathan, you'll create Jonathan with two A's or Jonathan with two N's so on

253
00:18:51,120 --> 00:18:57,340
first glance it looks very similar to everything that's in there. Another way is creating a

254
00:18:57,340 --> 00:19:02,160
temporary user. An acceptable duration when you're creating an IAM user, so identity

255
00:19:03,660 --> 00:19:10,280
management user, these sessions range from 900 seconds, about 15 minutes give or take, to

256
00:19:10,280 --> 00:19:19,700
roughly 1,000, sorry, 129,000 seconds which is about 36 hours as the default. These sessions,

257
00:19:20,500 --> 00:19:25,500
these sessions for the AWS owners are restricted to a maximum of one hour so you can create

258
00:19:25,500 --> 00:19:30,340
these, delete them, but those keys to log in will still be valid even though the user is

259
00:19:30,340 --> 00:19:34,880
gone. So they're not keeping too close of notice of like who's logging in and who's logging

260
00:19:34,880 --> 00:19:40,100
out. This is a very easy way to keep persistence. Another way is to create

261
00:19:40,280 --> 00:19:47,060
more user access keys. So by default, I believe you can have two to three access keys per user in

262
00:19:47,060 --> 00:19:52,500
there. So instead of making a new user or trying to typosquat a user, I'll just add an additional

263
00:19:52,500 --> 00:20:01,860
SSH key that I can use to log into various devices. And it brings us to roles. So let's say

264
00:20:01,860 --> 00:20:06,560
you're in an environment in which they have roughly 100 users. Yes, you could backdoor

265
00:20:06,560 --> 00:20:10,260
every single account there but you're going to have many, many, many, many, many keys. And you can

266
00:20:10,280 --> 00:20:13,620
keys to manage. Which brings us to roles. Roles are like let's

267
00:20:13,620 --> 00:20:17,160
say a superseding level above it to where you say role Bob has

268
00:20:17,160 --> 00:20:21,120
access to all these users X, Y, and Z. So it just makes it a

269
00:20:21,120 --> 00:20:24,020
little cleaner way to manage this and that goes back to the

270
00:20:24,020 --> 00:20:26,360
same thing which earlier we were talking about when a user

271
00:20:26,360 --> 00:20:29,760
deleted their keys are still valid. Well the one thing you

272
00:20:29,760 --> 00:20:33,760
will have to notice with roles is if one user loses that

273
00:20:33,760 --> 00:20:36,860
access in the role it could potentially affect the way that

274
00:20:36,860 --> 00:20:40,800
the role works as far as logging into devices. And

275
00:20:40,800 --> 00:20:45,360
backdooring AMIs. As I alluded earlier I don't have to

276
00:20:45,360 --> 00:20:49,640
necessarily hack your web application or your database or

277
00:20:49,640 --> 00:20:53,040
what have you. If I make myself a nice account or a cron job or

278
00:20:53,040 --> 00:20:55,340
a nice little script to scrape out whatever sensitive data you

279
00:20:55,340 --> 00:20:58,680
have and send it back to myself especially in ways where

280
00:20:58,680 --> 00:21:03,440
everyone loves auto scaling. So I only have to backdoor one AMI

281
00:21:03,440 --> 00:21:06,780
and then wait as auto scaling creates these new

282
00:21:06,780 --> 00:21:09,680
servers and destroys the old ones so eventually my infected

283
00:21:09,680 --> 00:21:12,760
AMI will eventually propagate throughout your entire network.

284
00:21:14,780 --> 00:21:18,080
And then another simple one is default security groups. The

285
00:21:18,080 --> 00:21:22,260
security groups as the VPCs you know the Amazon firewall. I can

286
00:21:22,260 --> 00:21:25,400
add very small things for myself or normally only allow port 80

287
00:21:25,400 --> 00:21:31,260
and 443 but I'll allow port 1111 or 4444 to allow my backdoor

288
00:21:31,260 --> 00:21:34,800
that I put in the AMI earlier to connect back whenever these

289
00:21:34,800 --> 00:21:35,720
instances are set up.

290
00:21:39,240 --> 00:21:43,380
And here's where I have attempts to be more secure. Make

291
00:21:43,380 --> 00:21:47,640
sure you segregate users in the least privilege model where if

292
00:21:47,640 --> 00:21:49,880
you only need to have access to X, Y, and Z you should only have

293
00:21:49,880 --> 00:21:53,380
access to this and not everything. You should utilize

294
00:21:53,380 --> 00:21:56,640
that least privilege model and not use the root account just

295
00:21:56,640 --> 00:21:59,120
like on your computer. You shouldn't run things as root. I'm

296
00:21:59,120 --> 00:22:01,400
sure there's some people in here who run everything in Kali Linux

297
00:22:01,400 --> 00:22:06,760
as root. Don't do that. Use instance profiles. While you're

298
00:22:06,780 --> 00:22:06,880
using your own browser you should always have access to your

299
00:22:06,880 --> 00:22:07,280
own browser. So, the last one is segmentation. So, if you have

300
00:22:07,280 --> 00:22:10,420
some metadata leakage that we talked about before, if you use

301
00:22:10,420 --> 00:22:15,120
proper segmentation then your risk is mitigated. So, while

302
00:22:15,120 --> 00:22:18,420
they may own one part of your network, they're only segmented

303
00:22:18,420 --> 00:22:21,940
to that one particular piece. And the last part is audit

304
00:22:21,940 --> 00:22:26,560
absolutely everything. While it may seem noisy to have everything

305
00:22:26,560 --> 00:22:30,460
in CloudTrail when people log in, when new keys are created,

306
00:22:30,640 --> 00:22:33,560
it can be very, very useful when you're going through and

307
00:22:33,560 --> 00:22:36,760
attempting to search through attacks and you're trying to do

308
00:22:36,760 --> 00:22:39,740
something that the attackers came through. AWS config is also

309
00:22:39,740 --> 00:22:44,060
very useful in this. It's an integrated service in AWS that

310
00:22:44,060 --> 00:22:47,760
enables automatic enforcement and verification of AWS resource

311
00:22:47,760 --> 00:22:51,580
modifications. For example, if you have an AMI that's changed,

312
00:22:51,940 --> 00:22:55,340
AWS config will tell you that it's changed and you should log

313
00:22:55,340 --> 00:22:58,760
this. Along with CloudWatch. CloudWatch is another integrated

314
00:22:58,760 --> 00:23:02,160
monitoring service for AWS that enables organizations to collect,

315
00:23:02,340 --> 00:23:06,140
monitor, and set alarms for anything that massive changes

316
00:23:06,140 --> 00:23:06,520
have happened.

317
00:23:06,760 --> 00:23:23,780
AWS. The questions? Anyone? Sir? I cannot hear you.

318
00:23:27,820 --> 00:23:36,740
Yeah. I'm familiar with some of them, yes. Are you asking

319
00:23:36,760 --> 00:23:40,300
about some of the potential risks from using them? Yes. So

320
00:23:40,300 --> 00:23:43,300
what I talked about earlier, so when you give these people access

321
00:23:43,300 --> 00:23:45,960
to your AWS network, usually you're going to set up a user for

322
00:23:45,960 --> 00:23:48,240
them or you're going to give them like an access token to log

323
00:23:48,240 --> 00:23:54,100
in. So you are shifting some of the risk onto them to keep their

324
00:23:54,100 --> 00:23:57,220
network secure. So if they lose control of their network and

325
00:23:57,220 --> 00:23:59,980
these access tokens are taken, people potentially have access

326
00:23:59,980 --> 00:24:02,340
to everything inside your network. Well, hopefully you've set

327
00:24:02,340 --> 00:24:06,480
aside proper user segmentation to where they only have access to

328
00:24:06,480 --> 00:24:09,980
the one or two or three things that they need. But just like

329
00:24:09,980 --> 00:24:11,960
when people are doing vulnerability scans, they often

330
00:24:11,960 --> 00:24:15,620
give domain admin to the user that's scanning and they do

331
00:24:15,620 --> 00:24:20,860
something that's very similar inside AWS. Sir? Do you have any

332
00:24:20,860 --> 00:24:29,440
thoughts on using Docker or containers? So containerized

333
00:24:29,440 --> 00:24:35,920
systems, well, I'm going to go ahead and say that in my opinion,

334
00:24:35,920 --> 00:24:38,920
they have some of the same vulnerabilities as autoscaling

335
00:24:39,580 --> 00:24:42,800
inside AWS. For example, you have your particular Docker image

336
00:24:42,800 --> 00:24:46,440
that you launch and destroy and launch and destroy. I can still

337
00:24:46,440 --> 00:24:49,100
backdoor that same image in the same way I would backdoor an AMI.

338
00:24:52,400 --> 00:24:55,400
Anyone else? Sir? What do you think about the S3

339
00:24:57,100 --> 00:25:00,560
problem that they have? Excuse me? What do you think about the

340
00:25:00,560 --> 00:25:05,840
S3 problem that Verizon has? That's going to be more of an uptime

341
00:25:05,920 --> 00:25:11,340
issue and I won't really comment on that. Anyone else? Sir?

342
00:25:20,020 --> 00:25:22,020
There's a logo in the bottom right corner.

343
00:25:27,680 --> 00:25:31,560
But honestly, any SIM that can ingest these logs and that you can

344
00:25:31,560 --> 00:25:35,600
create correlation on. The most important thing I'll say is creating

345
00:25:35,920 --> 00:25:39,220
a baseline. So what is normal inside your business? If you

346
00:25:39,220 --> 00:25:42,100
normally create one user every single Monday when you have new

347
00:25:42,100 --> 00:25:44,980
hires, that would be normal. So you can set a correlation role. If

348
00:25:44,980 --> 00:25:47,180
a user is created on a Tuesday or Wednesday, that would be

349
00:25:47,180 --> 00:25:50,620
abnormal to alert you. But like I said, any sort of SIM would be

350
00:25:50,620 --> 00:25:55,760
able to do it. But use the bottom right-hand corner logo. I saw one

351
00:25:55,760 --> 00:25:59,320
more hand in the back. Sir? Can you talk to the use of multiple

352
00:25:59,320 --> 00:26:05,640
accounts to increase your security profile in AWS? Yes. So the segmentation

353
00:26:05,640 --> 00:26:05,900
that we're talking about right now, we're talking about the

354
00:26:05,920 --> 00:26:07,840
security profile that you're speaking of earlier. So when you first

355
00:26:07,840 --> 00:26:10,760
create your account in AWS, you're generally given the root account,

356
00:26:10,920 --> 00:26:15,220
so to speak. From there, you want to create users that only have, for

357
00:26:15,220 --> 00:26:18,340
example, access to the SQL database and they only have access to launch

358
00:26:18,340 --> 00:26:22,140
these AMIs and they only have access to this. The permissions inside AWS

359
00:26:22,140 --> 00:26:26,440
are very rich and very full. If you've ever read the documentation, they

360
00:26:26,440 --> 00:26:30,080
go down very, very deep. I was talking more about actually using

361
00:26:30,080 --> 00:26:34,720
separate AWS accounts. Oh, I see. Not like user accounts, not IAM

362
00:26:34,720 --> 00:26:35,900
accounts, but actual user accounts. I see. So you're talking about

363
00:26:35,920 --> 00:26:39,520
AWS accounts, like numbered accounts. Yes. That's another way of

364
00:26:39,520 --> 00:26:43,160
segmentation. If you can segment from one root account up here, from,

365
00:26:43,260 --> 00:26:47,480
let's say, as you said, this AWS account that only has access, let's say,

366
00:26:47,940 --> 00:26:51,680
EC2 East, as opposed to this account that's a separate one that only has

367
00:26:51,680 --> 00:26:55,140
access to West 1 and they're completely different units, it's going to have

368
00:26:55,140 --> 00:26:58,800
about the same effect as user segmentation. Instead, it's going to be like

369
00:26:58,800 --> 00:27:04,720
zone segmentation, so to speak. Did I answer your question? Okay. I think

370
00:27:04,720 --> 00:27:06,380
we have room for one or two more.

371
00:27:09,300 --> 00:27:12,560
I was trying to escape. We have room for quite a lot of questions.

372
00:27:12,680 --> 00:27:14,800
I was trying to escape. It did not work.

373
00:27:17,580 --> 00:27:18,020
Anyone?

374
00:27:25,400 --> 00:27:25,840
Please.

375
00:27:25,840 --> 00:27:29,880
So I walked in a few minutes late. Forgive me if I missed something you

376
00:27:29,880 --> 00:27:30,280
already said.

377
00:27:33,240 --> 00:27:35,980
Finally someone uses the mic. Yeah, I walked in a few minutes late, so

378
00:27:35,980 --> 00:27:40,600
I apologize if I'm asking something that you've already mentioned. So a lot of

379
00:27:40,600 --> 00:27:44,060
the access that you're mentioning, the backdooring of the AMIs and stuff like

380
00:27:44,060 --> 00:27:49,780
that, is that assuming that those policies and whatnot have been applied to the

381
00:27:49,780 --> 00:27:53,760
roles or the groups that those users already possess, or are you talking some

382
00:27:53,760 --> 00:27:55,820
sort of privilege escalation?

383
00:27:55,840 --> 00:27:58,240
Is there a privilege escalation path that would be exploited in order to gain

384
00:27:58,240 --> 00:27:58,720
that access?

385
00:27:59,260 --> 00:28:02,560
So this is definitely like abusing credentials that they already have,

386
00:28:02,660 --> 00:28:05,740
whether they've scraped them via Bitbucket or what have you.

387
00:28:05,920 --> 00:28:06,240
Okay. Perfect.

388
00:28:06,380 --> 00:28:06,500
All right.

389
00:28:10,840 --> 00:28:11,920
You have a question, Eddie?

390
00:28:13,120 --> 00:28:13,980
Lambda functions.

391
00:28:14,920 --> 00:28:15,800
Lambda functions.

392
00:28:18,800 --> 00:28:23,260
Lambda functions are a nice black box inside AWS where you can define certain

393
00:28:23,260 --> 00:28:25,820
functions that are going to trigger off a certain set of functions that are

394
00:28:25,840 --> 00:28:26,660
going to trigger off a certain action happening.

395
00:28:27,080 --> 00:28:29,640
And honestly, that's as deep as I want to go into Lambda functions.

396
00:28:29,800 --> 00:28:30,260
Thank you, Eddie.

397
00:28:33,140 --> 00:28:33,540
Sir?

398
00:28:37,000 --> 00:28:38,700
Like Lambda or anything in general?

399
00:28:38,860 --> 00:28:39,180
Yes.

400
00:28:39,620 --> 00:28:41,040
Because no one understands Lambda.

401
00:28:48,980 --> 00:28:49,780
All right.

402
00:28:49,800 --> 00:28:54,480
Can you talk a little bit more about the initial scraping of the credentials to be

403
00:28:54,480 --> 00:28:55,520
able to get into an .

404
00:28:55,840 --> 00:28:56,000
Sure.

405
00:28:56,500 --> 00:29:02,000
So there's tools such as GitRob that can automatically scrape GitHub.

406
00:29:02,380 --> 00:29:06,180
And then so go on to Bitbucket and look at public repos.

407
00:29:06,260 --> 00:29:10,500
And then let's say download everything and grep for username, grep for password,

408
00:29:10,560 --> 00:29:11,460
grep for et cetera.

409
00:29:11,720 --> 00:29:14,380
You'll more than likely find many different user credentials.

410
00:29:14,620 --> 00:29:18,260
And then people often compromise different databases or what have you and just

411
00:29:18,260 --> 00:29:22,060
dump it on Pastebin and scrape those Pastebins, scrape those same things.

412
00:29:22,480 --> 00:29:25,820
So you can go from any amount of like AudraMagic or something like that.

413
00:29:25,840 --> 00:29:27,180
To yourself scraping.

414
00:29:29,160 --> 00:29:35,480
And then also since credential reuse from all like let's say the MySpace dump from a couple years ago.

415
00:29:36,520 --> 00:29:39,960
People are still using their passwords that they use in MySpace in high school.

416
00:29:40,120 --> 00:29:44,180
So you can take those and like go and try to brute force through to get into these same things.

417
00:29:44,380 --> 00:29:49,720
Or change small things from like fall 2017 to change it to fall 2015 or what have you.

418
00:29:50,200 --> 00:29:52,780
So it's all examples of those same credentials abuse.

419
00:29:53,840 --> 00:29:54,320
Sir?

420
00:29:56,720 --> 00:29:57,180
.

421
00:30:04,820 --> 00:30:09,380
I've seen them lock out one of my own instances when I leaked a key on Pastebin.

422
00:30:09,500 --> 00:30:11,160
So they seem to be fairly active.

423
00:30:11,360 --> 00:30:14,140
I can't say the response time but they blocked me.

424
00:30:21,940 --> 00:30:25,820
Amazon seems to roll out services with code names that don't really describe what they do.

425
00:30:25,820 --> 00:30:26,400
All the time.

426
00:30:26,580 --> 00:30:27,780
So I'm going to say yes.

427
00:30:31,620 --> 00:30:32,060
.

428
00:30:34,940 --> 00:30:40,320
He asked if there are any services sort of like Lambda that seem to be a black box that could be like leveraged by attackers.

429
00:30:40,940 --> 00:30:42,220
And I answered yes.

430
00:30:42,960 --> 00:30:44,500
And honestly we kind of don't know.

431
00:30:44,620 --> 00:30:46,740
They tend to just push out features all the time.

432
00:30:46,840 --> 00:30:53,900
And it takes some time to go through and see the security implications or risks that are introduced by using these services.

433
00:30:54,300 --> 00:30:54,740
.

434
00:30:57,380 --> 00:30:58,080
Sir.

435
00:31:00,900 --> 00:31:01,600
.

436
00:31:04,220 --> 00:31:04,920
.

437
00:31:04,920 --> 00:31:05,280
.

438
00:31:06,860 --> 00:31:07,560
.

439
00:31:07,560 --> 00:31:08,140
.

440
00:31:08,140 --> 00:31:08,180
.

441
00:31:08,180 --> 00:31:08,280
.

442
00:31:08,280 --> 00:31:08,300
.

443
00:31:08,300 --> 00:31:08,360
.

444
00:31:08,360 --> 00:31:08,660
.

445
00:31:08,660 --> 00:31:08,700
.

446
00:31:19,480 --> 00:31:20,180
.

447
00:31:20,180 --> 00:31:37,060
for like known CNCs to like known such techniques that are used. Okay, I see what you're asking.

448
00:31:37,260 --> 00:31:41,680
So, with the techniques that we presented right here, these are all tools that are built into

449
00:31:41,680 --> 00:31:50,160
Amazon that are just being abused in a way they weren't necessarily supposed to be used. But

450
00:31:50,160 --> 00:31:55,200
yeah, these are all known. These are all tools that we didn't design. These are all by AWS.

451
00:32:03,620 --> 00:32:10,700
All your defenses here have been about protecting your own account. Have you heard any rumors about

452
00:32:10,700 --> 00:32:17,260
being able to attack your account through another account on Amazon? That is weaknesses in their

453
00:32:17,260 --> 00:32:20,140
APIs or being able to jump from one account to another?

454
00:32:20,160 --> 00:32:28,360
As far as accounts that are in the same hierarchy. Like, for example, if I had an account that's

455
00:32:28,360 --> 00:32:32,100
like level three from here trying to work my way up to the root account, if the same, the

456
00:32:32,100 --> 00:32:36,820
passwords were similar, then yeah, you could jump up. But as far as pivoting to a completely

457
00:32:36,820 --> 00:32:40,920
different person, like, you know, Ming's AWS account, for example, I personally have no

458
00:32:40,920 --> 00:32:47,100
example, I have no ability to do that. Excuse me? Do you have any other questions?

459
00:32:50,160 --> 00:32:52,840
Well, you can, or you could do that kind of technically if they cross

460
00:32:52,840 --> 00:32:55,660
the account the icon minced so if you want to .

461
00:32:55,660 --> 00:32:57,080
Yes. .

462
00:33:02,200 --> 00:33:08,800
Okay. Yeah, I was more interested in if somebody from a random other account can use that to access

463
00:33:08,800 --> 00:33:10,800
my information in any way.

464
00:33:12,020 --> 00:33:12,880
Yeah. Okay. Yeah.

465
00:33:12,880 --> 00:33:20,140
Yeah. Um. Yeah. Okay. Yeah. Okay. Okay. Okay. Okay. Okay. Okay. Okay. So if we Bye let's just talk about Unterstützung. But let's just focus as much as we can

466
00:33:44,120 --> 00:33:47,720
question was answered. Anyone else?

467
00:33:50,780 --> 00:33:52,020
All right, I'm going to go ahead and say we're done.