1
00:00:00,000 --> 00:00:05,900
Speaker is Tyler Rozonki. His theme is social engineering with web analytics. Just a little

2
00:00:05,900 --> 00:00:10,560
background on Tyler here. He's a security consultant and a penetration tester for Trust

3
00:00:10,560 --> 00:00:15,720
Foundry, a Midwest-based security firm. He enjoys researching new technologies, studying

4
00:00:15,720 --> 00:00:19,680
them, understanding them, and identifying how an adversary could abuse it. So let's give

5
00:00:19,680 --> 00:00:20,500
him our attention. Thanks.

6
00:00:26,760 --> 00:00:32,480
Hi, everyone. Thanks for sticking around. So my name is Tyler Rozonki, like you said. I'm

7
00:00:32,480 --> 00:00:37,740
based out of Omaha, Nebraska. A little bit about me before I get going. I graduated from the

8
00:00:37,740 --> 00:00:42,080
University of Nebraska at Omaha with a degree in information assurance. From there I started

9
00:00:42,080 --> 00:00:47,340
with a Fortune 200 company and did some red teaming stuff. And then from there I'm now a

10
00:00:47,340 --> 00:00:50,480
security consultant slash penetration tester with Trust Foundry. And I've been working

11
00:00:50,480 --> 00:00:54,200
with them for a long time. I run a blog at zonksec.com. And when I'm not doing computer

12
00:00:54,200 --> 00:01:00,700
stuff, I like doing photography, videography, and doing other things. So a little disclaimer

13
00:01:00,700 --> 00:01:06,400
here. This information, this presentation is for information and educational purposes only.

14
00:01:06,880 --> 00:01:10,560
Neither I nor my employers are responsible for any trouble you get yourself into with this

15
00:01:10,560 --> 00:01:15,480
stuff. So use at your own risk. So before we talk about social engineering with web

16
00:01:15,480 --> 00:01:20,440
analytics, we should talk about what web analytics is. A formal definition is a web analytics

17
00:01:20,440 --> 00:01:20,460
engineering with web analytics, we should talk about what web analytics is. A formal definition is web

18
00:01:20,480 --> 00:01:24,680
analytics is the measurement, collection, analysis, and reporting of web data. What that

19
00:01:24,680 --> 00:01:29,660
really means is website operators use analytics on their website to track how users are getting

20
00:01:29,660 --> 00:01:34,020
there, what they're doing while they're there, maybe what browser they're in, all that sort of

21
00:01:34,020 --> 00:01:39,520
information, and then it gets aggregated and then they can paint pictures of what their users

22
00:01:39,520 --> 00:01:44,480
are doing. This is important because it helps website owners build better content, build better

23
00:01:44,480 --> 00:01:50,240
products, make decisions, and I'm sure you guys can think of reasons why that's useful. By far the

24
00:01:50,240 --> 00:01:56,460
top platform is Google analytics. Although others exist, they're few and far between in my

25
00:01:56,460 --> 00:01:59,840
experience so for the purpose of this talk we're pretty much going to be focusing on Google

26
00:01:59,840 --> 00:02:06,440
analytics. So this all started a while ago. I run analytics on my blog and I started seeing strange

27
00:02:06,440 --> 00:02:12,500
referrals. I saw stuff like free traffic, social buttons, make money online, and all these other

28
00:02:12,500 --> 00:02:19,980
like scammy sites and clearly these sites are not actually referring traffic to my site so I started

29
00:02:19,980 --> 00:02:25,540
thinking, what's going on? That doesn't seem legitimate. Being a penetration tester and red

30
00:02:25,540 --> 00:02:31,520
team kind of person, it started getting me wondering how I could do this and how I could do

31
00:02:31,520 --> 00:02:37,360
this for evil. So being the red team and penetration testing guy, I immediately started

32
00:02:37,360 --> 00:02:43,420
thinking of those applications which to me, if I can get a link or a domain in front of

33
00:02:43,420 --> 00:02:47,260
somebody, I want them to go there and I'm going to have an exploit waiting there or something.

34
00:02:47,260 --> 00:02:53,860
So it's sort of like fishing with Google analytics was the initial idea. So I thought that

35
00:02:53,860 --> 00:02:59,040
idea out a little bit more and this is sort of the scenario. I would do open source

36
00:02:59,040 --> 00:03:03,780
intelligence gathering on the target. I would understand what the target does, what their

37
00:03:03,780 --> 00:03:08,480
business is, who their customers are. And then I would try and buy a domain that I think their

38
00:03:08,480 --> 00:03:15,380
analytics admin would go to. An important distinction here is that the analytics admin,

39
00:03:15,380 --> 00:03:20,600
although that analytics was probably set up by a technology person, they probably handed it off

40
00:03:20,600 --> 00:03:26,600
to a business person or a marketing person to use that data. So we got to keep that in mind that

41
00:03:26,600 --> 00:03:32,080
it's like a marketing business person. And then we also have to think about the context of what

42
00:03:32,080 --> 00:03:38,180
our link actually is. It's going to be showing up as referrals. So as if our site is sending

43
00:03:38,180 --> 00:03:44,740
traffic to the target site. So it has to make sense that whatever domain we pick and choose, it

44
00:03:44,740 --> 00:03:48,880
has to make sense that that would be sending traffic there. So for example, if our target was a

45
00:03:48,880 --> 00:03:54,420
retail company, maybe buying a domain that looked like a consumer review site would be a good one

46
00:03:54,420 --> 00:04:01,480
because it has reasons to be sending traffic to that retail company. And the business admin

47
00:04:01,480 --> 00:04:06,760
person would probably be interested in what that review site is saying about their site. And

48
00:04:06,760 --> 00:04:10,840
then there's some other examples there. So after we do that, we're going to take that domain and

49
00:04:10,840 --> 00:04:14,720
point it to an attacker controlled site where maybe we have a browser, I don't know, maybe we have a

50
00:04:14,720 --> 00:04:20,180
exploit or a cross site request forgery vulnerability on the target site or maybe just a

51
00:04:20,180 --> 00:04:25,920
credential harvest. And that is where you, so if the target site has some sort of login and then

52
00:04:25,920 --> 00:04:30,180
they go to my domain and it presents a login that looks like something they're familiar and they

53
00:04:30,180 --> 00:04:35,720
log into it, you can steal their credentials. And so after we have that all set up, we're going to

54
00:04:35,720 --> 00:04:41,240
start spoofing referrals just like those scams did and hopefully our link will show up in front of

55
00:04:41,240 --> 00:04:44,700
the admin, percolate its way up through the analytics portal. And then we're going to take that

56
00:04:44,700 --> 00:04:50,000
URL, they click it, profit. So that idea made sense. After I kind of thought about it, I was

57
00:04:50,000 --> 00:04:55,540
like, okay, this seems possible. So how are those spammers doing it? And to understand that, I

58
00:04:55,540 --> 00:05:01,640
should probably figure out how analytics works. So from a high level, this is what it is. A user

59
00:05:01,640 --> 00:05:06,780
will go to a site wanting content. The server will respond with that content. And then inside

60
00:05:06,780 --> 00:05:13,260
that content will be some JavaScript that's telling the browser, hey, collect some information

61
00:05:13,260 --> 00:05:14,260
about your user.

62
00:05:14,700 --> 00:05:17,960
Collect some information about where they came from, maybe what links they're clicking. And

63
00:05:17,960 --> 00:05:23,440
then send that off to our analytics server. And then that server collects all that information and

64
00:05:23,440 --> 00:05:27,440
ties it all together and then presents it to website operators so they can see what the users

65
00:05:27,440 --> 00:05:33,940
are doing. So that's like the high level. The low level is this. This is the exact JavaScript

66
00:05:33,940 --> 00:05:38,400
that Google analytics gives you and tells you to put on all the pages you want to be tracked.

67
00:05:39,760 --> 00:05:44,540
The two important things to note here is first, this isn't the full script and that it's

68
00:05:44,540 --> 00:05:51,000
actually pulling in more and probably all of the juicy details are in there. And then secondly,

69
00:05:51,140 --> 00:05:56,660
that there's this string, the UA dash something, something, something. And this is actually the

70
00:05:56,660 --> 00:06:01,820
tracking ID, which is like the core component of how analytics works. This ID is the unique

71
00:06:01,820 --> 00:06:08,360
identifier. So all of Google analytics, all those requests are going to a singular end point.

72
00:06:08,660 --> 00:06:14,520
And so Google needs a way to say what data belongs to who. And so this unique identifier, it also has an

73
00:06:14,540 --> 00:06:19,900
is the way it does that. So that becomes very important later on. So if we can look at that

74
00:06:19,900 --> 00:06:24,260
JavaScript and figure out the request it's making to that analytics server, we could probably

75
00:06:24,800 --> 00:06:29,800
start figuring out how it works and maybe do it ourselves. So I saw two paths for it. I can

76
00:06:29,800 --> 00:06:35,000
either reverse engineer the JavaScript or I can proxy the browser and like catch that request

77
00:06:35,000 --> 00:06:39,480
and try and understand what it's doing. So let's take a look at that big JavaScript it was

78
00:06:39,480 --> 00:06:46,280
pulling in and maybe see if we can figure it out. That doesn't look like much fun. So on

79
00:06:46,280 --> 00:06:52,460
second thought, let's not mess with the JavaScript and do something else. And that's when a

80
00:06:52,460 --> 00:06:56,640
third option sort of presented itself. And that was that Google would just have amazing

81
00:06:56,640 --> 00:07:01,940
documentation about how it works. And here's a quick snapshot of all the required parameters. You

82
00:07:01,940 --> 00:07:09,240
probably can't read it but it's not that important. So the reason, you may be wondering why

83
00:07:09,240 --> 00:07:13,200
does Google provide this information? And I can't say for certain but I have a pretty good

84
00:07:13,200 --> 00:07:19,080
assumption. And that is because of the way it works, the page has to be reloaded for that

85
00:07:19,080 --> 00:07:24,860
information to be sent. The JavaScript we showed only runs when the page is reloaded. And so

86
00:07:24,860 --> 00:07:29,520
the way the web is going, we have these single page applications where the page loads once and

87
00:07:29,520 --> 00:07:34,820
then has lots of JavaScript to pull in data and redress the UI and the page never reloads. That

88
00:07:34,820 --> 00:07:39,220
would break analytics. And so those sites would lose that granularity. So I think it would be

89
00:07:39,220 --> 00:07:41,540
interesting to see how this works. So I assume that Google made all this information public so

90
00:07:41,540 --> 00:07:48,460
that these developers can get that granularity back and have that information. So with that

91
00:07:48,460 --> 00:07:55,140
documentation we can open up burp suite or any other tool that can make requests and we build out a

92
00:07:55,140 --> 00:08:00,980
request and you can see here that I made a request to, it made it look like traffic was coming

93
00:08:00,980 --> 00:08:06,100
from a fake domain. And I sent the request off and the server responded with some stuff and I

94
00:08:06,100 --> 00:08:09,200
logged into my portal and sure enough it made it look like something was coming from a fake domain.

95
00:08:09,220 --> 00:08:14,440
Somebody was on my site from a fake domain. And that's not true. That no one was there. So

96
00:08:14,440 --> 00:08:20,400
effectively what's happening is this. We're able to post directly to the analytics server and give

97
00:08:20,400 --> 00:08:24,900
it falsified information. And those activities that we're saying happened never actually

98
00:08:24,900 --> 00:08:31,180
happened. So that sort of proved the idea of okay we can get these links, we can make it look like

99
00:08:31,180 --> 00:08:35,200
sites coming from, we can make it look like traffic is coming from sites that aren't actually

100
00:08:35,200 --> 00:08:38,720
sending traffic. And we can set up those domains and that whole sort of scenario I talked about

101
00:08:38,720 --> 00:08:45,300
earlier is viable. And so then I went ahead and made some tools. I made a, the first version I

102
00:08:45,840 --> 00:08:52,620
wrote a script called Google Analytics attack and I got it added to the social engineering tool kit.

103
00:08:52,920 --> 00:08:57,180
And so if you have Kali Linux it has the social engineering tool kit and you actually have this

104
00:08:57,180 --> 00:09:02,100
previous version of the tool. And this is the menu how you get to it. And so when the script is

105
00:09:02,100 --> 00:09:08,640
running the bread and butter of it is the automatic mode which you give it two links. You give it

106
00:09:08,720 --> 00:09:14,500
the link of the target site which is the site that you want to fake a bunch of traffic to. And

107
00:09:14,500 --> 00:09:18,520
then the referral site which is the site where you want to make it look like lots of traffic is

108
00:09:18,520 --> 00:09:24,020
coming from. So that would be your juicy domain, your target site, your attacker site. And

109
00:09:24,720 --> 00:09:30,240
then the script will automatically make the request to the target site, grab that tracking ID,

110
00:09:30,380 --> 00:09:35,660
that unique identifier, and some other metadata to make the request work, fire it off and there

111
00:09:35,660 --> 00:09:38,700
you go. You're starting to make it look like fake traffic is showing up. So that's kind of the

112
00:09:42,660 --> 00:09:48,640
interesting thing that happened is there's this CID which stands for client ID. Sorry that's

113
00:09:48,640 --> 00:09:53,480
really small. But that's like a unique identifier for a user. And so if we don't randomize that

114
00:09:53,480 --> 00:09:58,300
parameter, if it's just a static thing, it looks like the same user is just going to the site over

115
00:09:58,300 --> 00:10:02,120
and over and over and that doesn't really make it look like lots of traffic. So you have to

116
00:10:02,120 --> 00:10:08,680
randomize that. That was something like I found later on. So I made that script and I actually

117
00:10:08,700 --> 00:10:13,700
blogged about it a little bit. And I sort of had my reservations about it because it seemed

118
00:10:13,700 --> 00:10:19,400
kind of far out there and like it wasn't doing anything crazy technical. But I did it anyways

119
00:10:19,400 --> 00:10:25,220
and it was fun and I enjoyed it. But then this article came out. And two things happened

120
00:10:25,220 --> 00:10:31,120
because of that. The first of which it validated me and I was like awesome, like that's a thing.

121
00:10:31,340 --> 00:10:38,340
And the second thing it made me think is there's more here. Like I was so focused on doing red teaming and penetration

122
00:10:38,340 --> 00:10:44,960
testing applications that I failed to consider anything else. And so that made me wonder what

123
00:10:44,960 --> 00:10:52,300
else could happen. And to sort of think about that, I had to understand how analytics is used.

124
00:10:52,480 --> 00:10:55,840
Because I use it in a very specific way but I'm sure there's other people that use it differently.

125
00:10:56,300 --> 00:11:01,820
So that means I need to go talk to other people who use this in the field in the real world and

126
00:11:02,500 --> 00:11:07,780
you know understand that and that might bring some enlightenment. So that's exactly what I did. I met

127
00:11:07,780 --> 00:11:11,740
up with various contacts I have in various industries and talked about hey how do you guys use

128
00:11:11,740 --> 00:11:15,680
analytics and what do you think about this. And we had some discussions and some interesting

129
00:11:15,680 --> 00:11:22,480
ideas came out of it. But first before we get into those scenarios we came up with a common theme.

130
00:11:23,800 --> 00:11:26,900
I mean if you're in here you probably understand what social engineering is so I'm not going to

131
00:11:26,900 --> 00:11:30,320
spend too much time on it. And you probably know more than I do. I'm just like some pen tester

132
00:11:30,320 --> 00:11:36,220
guy. But we know that humans love validation and reinforcement. And that is a very strong

133
00:11:38,120 --> 00:11:44,840
persuasion. And so if we kind of think about that with the context of analytics we can see

134
00:11:44,840 --> 00:11:50,760
something. And that is analytics traffic is kind of like a validation and a reinforcement of a

135
00:11:50,760 --> 00:11:55,580
website. If you're getting views, if you're getting hits, there's people out there that think

136
00:11:55,580 --> 00:12:03,840
your site is good. So if that's to be true and we can control analytics there might be some

137
00:12:03,840 --> 00:12:08,460
interesting things. That it may mean that we can control any decisions that are made on

138
00:12:08,460 --> 00:12:14,840
analytics. And it may mean we can manipulate any sort of measurements that are made with

139
00:12:14,840 --> 00:12:19,420
analytics. Any sort of measurements that are made with analytics being the measuring stick,

140
00:12:19,640 --> 00:12:24,500
that could be potentially manipulated. So with that I'll jump into some of the scenarios that I

141
00:12:24,500 --> 00:12:29,560
came up with. So the first one is sort of content control. Websites, you know, they make

142
00:12:29,560 --> 00:12:33,720
content and if they have a particular type of content A and a particular type of content

143
00:12:33,840 --> 00:12:38,860
B, and content B is getting lots of analytics traffic and seems really popular, and content A

144
00:12:38,860 --> 00:12:44,280
is not so much, they're probably going to make more of content B. And if you could apply that

145
00:12:44,280 --> 00:12:50,280
sort of across the board, you can sort of maybe shift what kind of content is being made. And

146
00:12:50,280 --> 00:12:56,700
therefore you can maybe reinforce and make certain political ideas, social ideas, you know,

147
00:12:56,700 --> 00:12:59,980
you guys can, your imaginations are good too so you can think of different things that could

148
00:12:59,980 --> 00:13:03,820
happen. But also the reverse is kind of possible. If we, you know, if we, you know, if we

149
00:13:03,820 --> 00:13:09,140
send traffic that looks to be coming from nefarious or antithetical sites, we could maybe

150
00:13:09,140 --> 00:13:14,860
discourage content. So if I write, if I have a website that's all about how cats are great, and I

151
00:13:14,860 --> 00:13:21,080
see a bunch of referrals are coming to my site from a cat that says dogs are great, a site that

152
00:13:21,080 --> 00:13:25,620
says dogs are great to my cat site, that may sort of trigger some self-consciousness, maybe

153
00:13:25,620 --> 00:13:30,380
they're making fun of me, or it may make me feel like a minority, like no one else cares about

154
00:13:30,380 --> 00:13:33,800
cats anymore, and I might stop making that content. So that's one of the things that I'm

155
00:13:33,800 --> 00:13:37,920
trying to do. And then nefarious is just sending traffic to these sites that, you know, comes

156
00:13:37,920 --> 00:13:41,920
from dark places of the web that are not so good. And that might discourage someone as well.

157
00:13:44,240 --> 00:13:50,120
Another scenario that I came up with was e-commerce control. So if I'm running an e-commerce

158
00:13:50,120 --> 00:13:54,140
site and I have some products on the site, and a particular product is receiving lots of

159
00:13:54,140 --> 00:13:58,080
traffic but no one is buying it, the main reason people don't buy stuff is because it's too

160
00:13:58,080 --> 00:14:03,720
expensive, I may think the price is too high, and I make that product go on sale, or maybe make

161
00:14:03,800 --> 00:14:10,480
the price drop. So that would be a form of interesting control as well. And e-commerce sites

162
00:14:10,480 --> 00:14:15,260
also, sometimes we'll talk about new features that are coming out for maybe their products. If

163
00:14:15,260 --> 00:14:20,520
they propose feature A and feature B, if we reinforce the idea that feature A is good, they

164
00:14:20,520 --> 00:14:24,480
will make feature A faster, better, and maybe forget about that feature B. So there's some more

165
00:14:24,480 --> 00:14:31,440
control. Another scenario that was interesting was some web development espionage. So

166
00:14:31,440 --> 00:14:33,780
there's lots of web development companies, and there's lots of web development companies that

167
00:14:33,800 --> 00:14:39,340
trust these web development companies to sort of handle their entire online presence, and these

168
00:14:39,340 --> 00:14:43,600
companies are probably using analytics, and share that with their customers because their

169
00:14:43,600 --> 00:14:48,520
customers need to make decisions with it. If there's a web development company who's a

170
00:14:48,520 --> 00:14:53,660
competitor, they may be interested in ruining that client relationship, and they could

171
00:14:53,660 --> 00:15:01,360
potentially do it by bombarding the analytics with traffic, and you would overflow it in such a

172
00:15:01,360 --> 00:15:03,780
way that you can no longer tell what's real and what's fake, and you can no longer tell what's

173
00:15:03,780 --> 00:15:10,660
fake, and that would sort of ruin their ability to have that insight. And because the client is

174
00:15:10,660 --> 00:15:15,580
trusting the, you know, their web development company, they may become disgruntled and, you

175
00:15:15,580 --> 00:15:19,820
know, we can't use this anymore. What happened? And that may cause them to leave.

176
00:15:21,680 --> 00:15:27,040
Additionally, if the client is seeing lots of referrals from, again, antithetical and

177
00:15:27,040 --> 00:15:32,840
nefarious sites, they may say, what the heck? Like, why are we getting all of these referrals from

178
00:15:32,840 --> 00:15:38,080
gambling and pornography sites? Like, that's not cool. We trusted you, and, you know, we're

179
00:15:38,080 --> 00:15:42,500
going to leave. Or if, you know, if they have a particular sort of customer they're trying to

180
00:15:42,500 --> 00:15:46,620
reach, and they're receiving lots of traffic from the opposite type of customer, the

181
00:15:46,620 --> 00:15:54,020
antithetical customer, again, they may become disgruntled and leave. The next scenario is kind

182
00:15:54,020 --> 00:15:58,200
of out there, so I'm going to ask you to put on your tinfoil hats with me, but if we can

183
00:15:58,200 --> 00:16:02,820
assume that a nation state was able to subpoena the analytics data and sort of have a

184
00:16:02,840 --> 00:16:09,080
mass data set, we could maybe assume that that nation state is using the analytics to identify

185
00:16:09,540 --> 00:16:16,860
suspicious websites and operators. Maybe they're looking for, you know, terrorist organizations or

186
00:16:16,860 --> 00:16:21,880
child pornography rings or any of that stuff. There are organizations that would be

187
00:16:21,880 --> 00:16:29,120
interesting in identifying and stopping these things. And so if they're using analytics to do

188
00:16:29,120 --> 00:16:32,820
that, and we can control what analytics sees, you know, we can control what analytics sees, you know,

189
00:16:32,840 --> 00:16:39,080
if we can identify already known bad sites and refer traffic from those bad sites to innocent

190
00:16:39,080 --> 00:16:46,440
sites, we may kick off an investigation or maybe frame these innocent sites. Additionally, the

191
00:16:46,440 --> 00:16:53,240
inverse is sort of possible, where if we're bad guys and we have lots of bad guys coming to our

192
00:16:53,240 --> 00:17:00,080
site, if we can sort of murky the water there and send lots of good traffic, it may, you know, make it

193
00:17:00,080 --> 00:17:07,000
difficult to see what's actually going on and kind of act like a cloak. The next scenario kind of goes

194
00:17:07,000 --> 00:17:14,520
back to the main thing that kicked all of this off, which was sort of scammy online stuff. And to talk

195
00:17:14,520 --> 00:17:19,180
about this one, the first thing we have to mention is that SEO is actually not affected by analytics.

196
00:17:19,720 --> 00:17:27,020
SEO is search engine optimization. It's basically how techniques to increase your position on

197
00:17:27,600 --> 00:17:30,060
Google, like to increase your rank and in other sites. So, I'm just going to talk about how SEO can help

198
00:17:30,080 --> 00:17:34,720
search engines too. Analytics doesn't play any factor in that

199
00:17:34,720 --> 00:17:37,420
according to Google. They said, Google has come out and said,

200
00:17:37,560 --> 00:17:40,400
hey, like, not everyone is in analytics so it's not fair if we

201
00:17:40,400 --> 00:17:43,480
use that to decide how to do rank or get to keep that sort of

202
00:17:43,480 --> 00:17:46,340
out of the playing field. But people don't necessarily

203
00:17:46,340 --> 00:17:50,520
understand that. Additionally, analytics traffic isn't real.

204
00:17:50,720 --> 00:17:54,000
People don't understand that either. And so with those two

205
00:17:54,000 --> 00:17:56,500
fallacies at play, there are a lot of scams that are possible.

206
00:17:57,140 --> 00:18:02,540
Maybe I come to your company and I say, hi, I'm an SEO ninja and I

207
00:18:02,540 --> 00:18:06,780
can help your site get a lot more traffic and you should pay

208
00:18:06,780 --> 00:18:09,840
me. Or maybe I say, hey, don't pay me anything and if it

209
00:18:09,840 --> 00:18:13,620
happens, you know, no risk, if it happens, you owe me this much per

210
00:18:13,620 --> 00:18:17,700
this increase. And then if we can control the analytics, we

211
00:18:17,700 --> 00:18:21,900
can make those things happen and you get paid. If we can

212
00:18:21,900 --> 00:18:25,360
control geographical attributes of analytics so we can make it

213
00:18:25,360 --> 00:18:26,480
look like users are coming from somewhere else, we can control

214
00:18:26,500 --> 00:18:29,660
specific spots. There's also some SEO things you can do there,

215
00:18:29,700 --> 00:18:32,220
too. Maybe I come to your company and say, hey, I don't

216
00:18:32,220 --> 00:18:35,440
think you're doing very well on the east coast. I can get you

217
00:18:35,440 --> 00:18:38,960
more users from the east coast. You should pay me money. And

218
00:18:39,480 --> 00:18:44,400
again, that can happen. And then the oldest one is people buy

219
00:18:44,400 --> 00:18:48,140
traffic all the time. And so if they're using Google analytics as

220
00:18:48,140 --> 00:18:50,560
their measuring stick to say if traffic is coming to their site

221
00:18:50,560 --> 00:18:53,900
or not, that could be manipulated. And so this stuff

222
00:18:53,900 --> 00:18:56,480
exists. Here's an example of people buying, you know, a

223
00:18:56,500 --> 00:19:02,080
$25,000 hits on Fifer for $5. So not a lot of money, but it's

224
00:19:02,080 --> 00:19:07,680
out there. An interesting thing that came out of this is not

225
00:19:07,680 --> 00:19:10,520
only do the good guys use analytics, but bad guys use it,

226
00:19:10,580 --> 00:19:14,260
too. Domainers and ad fraud networks and malware networks

227
00:19:14,260 --> 00:19:17,180
have been identified to be using analytics. Because just like the

228
00:19:17,180 --> 00:19:22,260
good guys, they need to know where their users, in this case

229
00:19:22,260 --> 00:19:25,060
victims, are coming from because that helps them, you know,

230
00:19:25,060 --> 00:19:26,480
choose where they go next. And, you know, that's kind of the

231
00:19:26,500 --> 00:19:29,700
reason they set up new systems. Which actually is interesting

232
00:19:29,700 --> 00:19:33,140
because it has become a form of attribution. If we have two known

233
00:19:33,140 --> 00:19:36,380
bad sites and they have the same tracking ID, we can assume

234
00:19:36,380 --> 00:19:42,540
that the same operators are behind both domains. So what

235
00:19:42,540 --> 00:19:46,520
could be done here is, again, if we can just ruin the

236
00:19:46,520 --> 00:19:51,020
integrity of their analytics data, that might hurt their

237
00:19:51,020 --> 00:19:56,480
ability to operate. So with all this new stuff that we're

238
00:19:56,500 --> 00:19:58,300
dealing with, the old tooling is just not good enough anymore.

239
00:19:58,960 --> 00:20:02,380
So I built a new tool, which I, this is the first time I've

240
00:20:02,380 --> 00:20:04,800
shown it to a crowd, so it's actually going to be released

241
00:20:04,800 --> 00:20:10,180
today, called Google Analytics Attack NG. And to talk about

242
00:20:10,180 --> 00:20:13,500
what we did new with it, I need to talk about how the old one

243
00:20:13,500 --> 00:20:19,960
failed. And the biggest thing it did wrong was user emulation. So

244
00:20:19,960 --> 00:20:23,900
with the old tool, it looked like users showed up on the

245
00:20:23,900 --> 00:20:26,280
target site and then disappeared. They didn't

246
00:20:26,280 --> 00:20:26,480
click on the target site and then disappeared. They didn't

247
00:20:26,480 --> 00:20:29,620
click on anything. They didn't go anywhere else. And that made

248
00:20:29,620 --> 00:20:33,460
an incredibly high bounce rate, which if you know any sort of

249
00:20:33,460 --> 00:20:36,640
stuff about the website, you know the bounce rate is when

250
00:20:36,640 --> 00:20:39,340
someone comes to your site, if it's a bounce rate of 100%, that

251
00:20:39,340 --> 00:20:41,980
means people showed up on your site and then left. They didn't

252
00:20:41,980 --> 00:20:44,460
click around, which isn't a good thing. You want to try and

253
00:20:44,460 --> 00:20:50,720
retain users. So because of that, it made the users look not

254
00:20:50,720 --> 00:20:53,920
legitimate. And so for these more sophisticated attacks, we

255
00:20:53,920 --> 00:20:55,500
need to make the users look real.

256
00:20:57,320 --> 00:21:01,060
Because all of the requests to the analytics were previously

257
00:21:01,060 --> 00:21:06,380
coming from whatever IP the script was running on, that made

258
00:21:06,380 --> 00:21:08,600
it look like the same geographical location because

259
00:21:08,600 --> 00:21:11,860
Google uses the IP to decide where traffic is coming from. So

260
00:21:11,860 --> 00:21:14,060
it made it look like all the users are coming from one spot.

261
00:21:14,420 --> 00:21:19,080
Again, not a good way to make it look like real users. And with

262
00:21:19,080 --> 00:21:23,220
the sort of IP address stuff, if that's the attacker IP and

263
00:21:23,220 --> 00:21:25,880
that's sort of, you know, your attacker machine, that's bad

264
00:21:25,880 --> 00:21:26,460
operation. It's not a good way to make it look like real users.

265
00:21:26,460 --> 00:21:31,340
And that's a good way to get in trouble. So we need to make

266
00:21:31,340 --> 00:21:36,580
requests to Google analytics from a IP that's not ours. And

267
00:21:38,400 --> 00:21:41,000
what's even worse than making requests to analytics is we

268
00:21:41,000 --> 00:21:43,220
actually were making a request to the target site because we

269
00:21:43,220 --> 00:21:46,740
were trying to get that tracking ID. We left our IP address on

270
00:21:46,740 --> 00:21:52,080
the victim's machine, which is not good. And then the last

271
00:21:52,080 --> 00:21:54,860
thing that the previous version didn't do well is it failed to

272
00:21:54,860 --> 00:21:56,440
account for other perspectives. I was very, very

273
00:21:56,440 --> 00:21:59,140
focused on making pen testing and red teaming applications that

274
00:21:59,140 --> 00:22:02,400
I kind of failed to consider all of those other scenarios that I

275
00:22:02,400 --> 00:22:05,900
mentioned. So you may be wondering what's good user

276
00:22:05,900 --> 00:22:08,640
emulation. And the best way to demonstrate that is to actually

277
00:22:08,640 --> 00:22:12,100
kind of peel back analytics, the portal, and show you what it

278
00:22:12,100 --> 00:22:17,580
looks like. So this is a screen cap from Google analytics. And

279
00:22:17,580 --> 00:22:20,740
you can see, it shows where the users are going when they land

280
00:22:20,740 --> 00:22:25,320
on your site. And this is an example of bad user emulation

281
00:22:25,320 --> 00:22:26,420
because the user emulation is bad. And you can see that the

282
00:22:26,420 --> 00:22:29,400
users show up and they drop off. They don't click anywhere.

283
00:22:30,520 --> 00:22:33,000
Except the one on the bottom where the user clicked to one

284
00:22:33,000 --> 00:22:36,840
page. But overall this demonstrates bad user

285
00:22:36,840 --> 00:22:40,780
emulation. What good user emulation looks like is they

286
00:22:40,780 --> 00:22:43,820
land on your page and then they click around. They go to other

287
00:22:43,820 --> 00:22:48,480
pages and they interact with the site. But that's sort of a

288
00:22:48,480 --> 00:22:51,620
slippery slope too because not all, you know, if all these

289
00:22:52,100 --> 00:22:56,340
users showed up and they went to like 10 pages, normal users

290
00:22:56,420 --> 00:22:59,580
don't do that. They don't click to 10 pages and then, you know, on

291
00:22:59,580 --> 00:23:04,620
average it's low. So there's kind of give and take there. The next

292
00:23:04,620 --> 00:23:07,940
view, the main columns we're interested in is the bounce rate

293
00:23:07,940 --> 00:23:11,240
and the pages per session and average session duration which are

294
00:23:11,240 --> 00:23:15,200
all sort of between those three metrics you can decide what the

295
00:23:15,200 --> 00:23:20,240
users were doing. So the row that's most interesting, well

296
00:23:20,240 --> 00:23:22,560
there's a few we're going to look at. But number four, which

297
00:23:22,560 --> 00:23:26,000
is GitHub.com, which is actual legitimate traffic that came to

298
00:23:26,000 --> 00:23:31,060
my blog, 86% of those users bounced away. That means they

299
00:23:31,060 --> 00:23:33,780
came to my site and they left. But a handful of them stuck

300
00:23:33,780 --> 00:23:37,640
around and when they did, on average they visited 1.3 pages

301
00:23:37,640 --> 00:23:41,020
and they were on average there for a minute and five seconds.

302
00:23:41,340 --> 00:23:48,860
That's pretty good users. The one right below, lolol.com, 100%

303
00:23:48,860 --> 00:23:51,960
of those users bounced, meaning they came to the site and they

304
00:23:51,960 --> 00:23:55,940
left. They visited that one page and they were there for

305
00:23:56,000 --> 00:24:02,280
zero seconds. So that's a bad user. That's spam. And an

306
00:24:02,280 --> 00:24:05,060
example of taking it sort of too far, like I mentioned before, if

307
00:24:05,060 --> 00:24:09,600
we look at row nine, gethackthear.com, those users,

308
00:24:10,200 --> 00:24:14,480
the bounce rate was nine point, almost 10%, which that means

309
00:24:14,480 --> 00:24:17,360
lots of people clicked to other pages and on average they almost

310
00:24:17,360 --> 00:24:20,660
went to four pages per session and were there for 47 seconds.

311
00:24:21,060 --> 00:24:24,140
That's an example of kind of taking it too far. Users don't

312
00:24:24,600 --> 00:24:25,460
interact that much.

313
00:24:26,280 --> 00:24:29,500
So in this new version, we want to have better user emulation,

314
00:24:30,000 --> 00:24:33,580
which because better user emulation involves waiting in

315
00:24:33,580 --> 00:24:37,060
real time to give the appearance of an actual user, we need to

316
00:24:37,060 --> 00:24:40,100
make the application threaded so that we can have better

317
00:24:40,100 --> 00:24:44,880
throughput. And we need to do geographical spoofing to

318
00:24:44,880 --> 00:24:49,960
protect not only the IP, but to make it seem like users are

319
00:24:49,960 --> 00:24:54,000
coming from more than one spot. We need to do some auto URLs,

320
00:24:54,240 --> 00:24:55,980
which we'll talk about in a little bit. And then we need to

321
00:24:56,000 --> 00:25:00,220
have proxy support to use Tor and protect ourselves for a

322
00:25:00,220 --> 00:25:05,120
better operational security. So to do better user emulation, I

323
00:25:05,120 --> 00:25:09,800
kind of broke down what that means and this is the way I

324
00:25:11,440 --> 00:25:15,560
organized what that means. So a session or one user interaction

325
00:25:15,560 --> 00:25:20,220
involves three types of URLs. The referral, which is where

326
00:25:20,220 --> 00:25:24,100
they're coming from. The target, what page they're landing on. And

327
00:25:24,100 --> 00:25:25,980
the bounce URL, which is where they refer, as an example, which is

328
00:25:26,000 --> 00:25:31,460
where they go afterwards, what they bounce to and click to. And the attributes of a bounce is

329
00:25:31,460 --> 00:25:36,740
how many bounces they go to, how many pages they go beyond and how long they're on those pages

330
00:25:36,740 --> 00:25:43,500
when they do. And this will come into play later when I show you the tool. So the concept of

331
00:25:43,500 --> 00:25:49,280
auto URLs, in some of those scenarios we mentioned, it would be a good thing to be able to

332
00:25:49,280 --> 00:25:58,940
control specific referral URLs, specific target URLs, specific bounce URLs and maybe have not

333
00:25:58,940 --> 00:26:04,880
only one but multiples of each. So sometimes you want that granularity but sometimes you

334
00:26:04,880 --> 00:26:09,520
don't. Let's say I just want to have a website receive lots of traffic and I don't really

335
00:26:09,520 --> 00:26:14,680
care where it's coming from but I want it to appear to be coming from a place of a certain

336
00:26:14,680 --> 00:26:19,260
topic. What if I did a Google search with a certain key word and I wanted to have a

337
00:26:19,280 --> 00:26:24,680
site that gave me lots of sites and it looked like those sites were referring traffic. So

338
00:26:24,680 --> 00:26:32,160
that's kind of the idea. So, for example, if we did a Google search for good hacker blogs and

339
00:26:32,160 --> 00:26:36,660
we pointed that to my blog, that would generate a lot of traffic that would maybe reinforce my,

340
00:26:36,700 --> 00:26:40,460
you know, if I'm running that blog that people are interested in, that I'm doing good work.

341
00:26:40,860 --> 00:26:47,220
And then we can apply that same sort of technique to grabbing target URLs and bounce URLs. So I

342
00:26:47,220 --> 00:26:49,260
have a quick demo to show some of the things that we can do. So I'm going to go ahead and show

343
00:26:49,280 --> 00:26:49,800
you some of the different stuff.

344
00:26:56,760 --> 00:27:00,740
And I'm on the con Wi-Fi so hopefully it stays strong.

345
00:27:07,040 --> 00:27:12,420
It could be messing with me. I just kicked one off and we're going to talk about the parameters

346
00:27:12,420 --> 00:27:18,180
and we'll talk about a little bit of the output. So the script is in referral mode and we are

347
00:27:18,180 --> 00:27:21,560
going to send traffic to zonksec.com which is my blog and

348
00:27:21,560 --> 00:27:23,880
we're going to make it look like traffic is coming from

349
00:27:23,880 --> 00:27:27,900
defconiscancelled.com. And these users are going to bounce to

350
00:27:27,900 --> 00:27:31,020
two other pages while on my site and we're going to add a delay

351
00:27:31,020 --> 00:27:34,920
there of about 60 seconds so they spend some time there. If

352
00:27:34,920 --> 00:27:38,660
all of the users were waiting exactly 60 seconds that wouldn't

353
00:27:38,660 --> 00:27:41,100
be good because that would be a way to determine that the

354
00:27:41,100 --> 00:27:44,780
traffic is false. So I introduced the idea of jitter

355
00:27:44,780 --> 00:27:48,900
and if you've used tools it's basically a way to like insert

356
00:27:48,900 --> 00:27:52,680
some randomness into the delay. And so with the jitter being

357
00:27:52,680 --> 00:27:56,860
one these users will either wait zero seconds or 60. If the jitter

358
00:27:56,860 --> 00:28:01,580
was .5 they would either wait or not either but somewhere in

359
00:28:01,580 --> 00:28:05,080
between zero and 60. If the jitter was .5 they would be

360
00:28:05,080 --> 00:28:07,720
somewhere between 30 and 60. And so you can kind of control

361
00:28:07,720 --> 00:28:11,760
the randomness. And then this number and 10 is saying we're

362
00:28:11,760 --> 00:28:13,960
going to send 10 requests and then we're going to do it over

363
00:28:13,960 --> 00:28:14,760
to the jitter. And then we're going to send 10 requests and

364
00:28:14,760 --> 00:28:19,860
two threads. And so this has been running and the first output

365
00:28:19,860 --> 00:28:23,760
says geo list was not provided, we're going to randomize requests

366
00:28:23,760 --> 00:28:27,440
from US cities. So the tool gives the ability to specify

367
00:28:27,440 --> 00:28:30,800
geographical locations. Google does this with what's called a

368
00:28:30,800 --> 00:28:34,500
criteria ID which is used both in AdWords and in Google

369
00:28:34,500 --> 00:28:38,700
Analytics. This is just basically, you know, this US

370
00:28:38,700 --> 00:28:42,080
city has this number, this state has this number and it's just a

371
00:28:42,080 --> 00:28:44,520
way of representing that stuff. And so because we didn't provide

372
00:28:44,520 --> 00:28:48,300
that, the script automatically just decides we're just going to make it look like stuff is coming

373
00:28:48,300 --> 00:28:53,720
from all over the U.S. And it saw we didn't provide a tracking ID, so it went out and grabbed

374
00:28:53,720 --> 00:28:58,880
that for us. And then we told it that we wanted to have two bounces, so it's going to bounce to

375
00:28:58,880 --> 00:29:04,220
other stuff on zonksec.com, but we didn't tell it what URLs to do, so it automatically did a

376
00:29:04,220 --> 00:29:11,160
Google search and grabbed other URLs on zonksec.com to bounce to. And so you can see these

377
00:29:11,160 --> 00:29:17,940
sessions are starting to come back. The first one had, you know, you can see this client ID and

378
00:29:17,940 --> 00:29:24,600
it had this geographical location ID and its behavior was it looked like the user was referred

379
00:29:24,600 --> 00:29:30,140
from DEF CON is cancelled.com and then they landed on the home page where they sat around for

380
00:29:30,140 --> 00:29:34,760
42 seconds and then clicked on to another page and were there for 24 seconds and then another

381
00:29:34,760 --> 00:29:40,460
page and dropped off. And you can see all of those delays are randomized as it's going. So if

382
00:29:40,460 --> 00:29:41,140
we hop over to the next slide.

383
00:29:41,160 --> 00:29:48,780
Let's go to analytics and take a look at what's going on. We can see we have six users on our

384
00:29:48,780 --> 00:29:54,120
site. They're all coming from DEF CON is cancelled.com and the traffic is coming from all

385
00:29:54,120 --> 00:30:00,540
over the place. So I'm sort of running low on time. There's other examples I was going to show

386
00:30:00,540 --> 00:30:06,100
that demonstrate other capabilities, but there is more stuff here that different flags that let

387
00:30:06,100 --> 00:30:10,640
you control all sorts of different stuff. So I'm going to jump back into the PowerPoint.

388
00:30:14,340 --> 00:30:24,420
This one. Oh, and then I got to skip through all of these screenshots because the demo gods did

389
00:30:24,420 --> 00:30:31,000
not fail me. So possible improvements. As you make these more granular attacks, there's a lot of

390
00:30:31,000 --> 00:30:35,800
command line arguments and it gets really tricky to follow. So taking in a CSV configuration

391
00:30:35,800 --> 00:30:41,140
files would make it a lot easier. I would love to be able to emulate source code. So I'm going to

392
00:30:42,120 --> 00:30:42,560
take a look at those and then if I'm able to update theñabla. And if that's the case, and now

393
00:30:42,560 --> 00:30:44,220
being able to control the and so being able to control does a lot of stuff with social media.

394
00:30:44,720 --> 00:30:50,680
So being able to control that would be interesting. And then currently, the user agent that it

395
00:30:50,680 --> 00:30:57,900
appears all the users are doing are the same. And so randomizing that would be nice. Some bonus

396
00:30:57,900 --> 00:31:03,100
bonus content that I came across, because you saw analytics was loading all of that

397
00:31:03,100 --> 00:31:07,860
data in real time, when you start sending lots and lots and lots of data, the browser

398
00:31:07,860 --> 00:31:12,540
gets really slow and can sometimes crash. I thought that was interesting because that

399
00:31:12,540 --> 00:31:16,300
may be another potential scenario where you just don't even make analytics usable for

400
00:31:16,300 --> 00:31:21,460
them. And then another interesting thing that came out was if you're doing some sort of

401
00:31:21,460 --> 00:31:26,360
command and control for botnets, it would be a really interesting idea for agents to

402
00:31:26,360 --> 00:31:32,680
send data out of networks by posting to analytics. But that's a different topic. So you

403
00:31:32,680 --> 00:31:37,400
may be wondering how can you prevent this from happening. The first one is user awareness, so

404
00:31:37,400 --> 00:31:41,920
teaching your analytics admins that this is possible and that they probably should be careful

405
00:31:41,920 --> 00:31:46,580
about clicking links while they're in analytics. You may have noticed that this whole thing

406
00:31:46,580 --> 00:31:51,240
sort of revolves around the tracking ID, and if we can get that, we can make it look like

407
00:31:51,240 --> 00:31:55,480
data is coming to your site. So if there was a way to protect it, that would be useful. The

408
00:31:55,480 --> 00:31:56,340
idea I came up with was to make it look like data is coming to your site. So if there was a way to

409
00:31:56,340 --> 00:31:58,420
protect it, that would be useful. The idea I came up with is you don't put that JavaScript on any of

410
00:31:58,420 --> 00:32:02,520
your pages and you have some script on the back end that's looking at server logs and then post

411
00:32:02,520 --> 00:32:09,600
analytics on those users' behalf so they never, their client's not doing it. And then that sort

412
00:32:09,600 --> 00:32:13,380
of fixed things going forward, but if you for some reason want to look backwards and see what

413
00:32:13,380 --> 00:32:16,960
data is real and what's not, you'd have to export all your analytics data and corroborate it

414
00:32:16,960 --> 00:32:23,380
with your server logs. In conclusion, analytics traffic is not real traffic, therefore it can be

415
00:32:23,380 --> 00:32:26,320
spoofed, and you should be really careful when clicking on things and anything that you're

416
00:32:26,320 --> 00:32:30,740
using in analytics. And any decisions you make with analytics could potentially be manipulated,

417
00:32:30,960 --> 00:32:35,280
and any sort of measurements with analytics as the measuring stick could be manipulated as well.

418
00:32:36,720 --> 00:32:41,720
I will be posting the code on GitHub, and I'll probably have a user guide in these slides up on

419
00:32:41,720 --> 00:32:46,340
my blog in a future post. So thanks for listening, and I'll be happy to answer any questions you

420
00:32:46,340 --> 00:32:46,600
may have.