1 1 00:00:00,510 --> 00:00:02,280 Beaconing. 2 2 00:00:02,280 --> 00:00:04,740 Now when your computer gets infected 3 3 00:00:04,740 --> 00:00:08,040 with some kind of malware, it can have that malware run 4 4 00:00:08,040 --> 00:00:12,270 commands on it, but it's only going to be a one-way street. 5 5 00:00:12,270 --> 00:00:14,460 For an attacker to be able to have two-way control, 6 6 00:00:14,460 --> 00:00:17,490 it needs to reach back to a command and control server. 7 7 00:00:17,490 --> 00:00:20,670 One of the ways it does this is by using beaconing. 8 8 00:00:20,670 --> 00:00:23,640 Now beaconing is a means for a network node to advertise 9 9 00:00:23,640 --> 00:00:26,790 its presence and establish a link with other nodes. 10 10 00:00:26,790 --> 00:00:28,980 So if we have somebody who's been infected, 11 11 00:00:28,980 --> 00:00:31,230 once it's been infected, it's going to reach back 12 12 00:00:31,230 --> 00:00:34,920 to the central C2 server and say, "Hey, I've been infected. 13 13 00:00:34,920 --> 00:00:37,710 I'm here now as part of your resource pool." 14 14 00:00:37,710 --> 00:00:40,500 Now beaconing is not just a malicious thing, though. 15 15 00:00:40,500 --> 00:00:42,690 Beaconing can be used legitimately. 16 16 00:00:42,690 --> 00:00:45,570 For example, inside of your wireless access points, 17 17 00:00:45,570 --> 00:00:48,120 there's something called a beacon management frame 18 18 00:00:48,120 --> 00:00:50,430 and this is sent from a wireless access point 19 19 00:00:50,430 --> 00:00:53,047 to other wireless access points in the area to say, 20 20 00:00:53,047 --> 00:00:57,120 "Hey, I'm here, I'm awake, and I'm ready to accept traffic." 21 21 00:00:57,120 --> 00:00:59,220 Now malicious beaconing, on the other hand, will 22 22 00:00:59,220 --> 00:01:01,320 usually take the form of a simple ping 23 23 00:01:01,320 --> 00:01:04,350 or a heartbeat to verify the bot is still alive 24 24 00:01:04,350 --> 00:01:06,330 inside of this botnet. 25 25 00:01:06,330 --> 00:01:09,330 Now this beaconing can happen at regular intervals 26 26 00:01:09,330 --> 00:01:11,400 or it can happen at different times depending 27 27 00:01:11,400 --> 00:01:12,720 on how it's configured. 28 28 00:01:12,720 --> 00:01:15,270 But the whole goal of beaconing is to send out a message 29 29 00:01:15,270 --> 00:01:18,997 from a victimized machine back to a C2 server to say, 30 30 00:01:18,997 --> 00:01:22,350 "Hey, I'm here and I'm part of your botnet now." 31 31 00:01:22,350 --> 00:01:24,750 We'll talk about the different communication channels used 32 32 00:01:24,750 --> 00:01:26,700 by this beaconing in just a little bit. 33 33 00:01:27,540 --> 00:01:30,660 So at this point, we have a host, it's been victimized, 34 34 00:01:30,660 --> 00:01:32,160 and it's beaconing out. 35 35 00:01:32,160 --> 00:01:34,410 Now the easiest thing for us to do would be to figure out 36 36 00:01:34,410 --> 00:01:35,250 where it's beaconing to 37 37 00:01:35,250 --> 00:01:37,620 and simply block that address, right? 38 38 00:01:37,620 --> 00:01:38,730 Well, because of that, 39 39 00:01:38,730 --> 00:01:41,250 attackers have started evolving their process. 40 40 00:01:41,250 --> 00:01:44,250 In the old days, they would beacon to a common IP address 41 41 00:01:44,250 --> 00:01:47,340 or to a common domain name, but to make it more difficult 42 42 00:01:47,340 --> 00:01:50,220 for us to identify or block them as defenders, 43 43 00:01:50,220 --> 00:01:53,250 these type of malware are now changing their DNS names 44 44 00:01:53,250 --> 00:01:57,150 and their IP addresses all the time using things like DGA, 45 45 00:01:57,150 --> 00:02:01,050 domain generation algorithms, and fast flux DNS. 46 46 00:02:01,050 --> 00:02:03,150 So with all these changes happening, 47 47 00:02:03,150 --> 00:02:05,670 how can we detect this beaconing activity? 48 48 00:02:05,670 --> 00:02:08,340 Well, one of the most common ways is by capturing metadata 49 49 00:02:08,340 --> 00:02:10,710 about all those sessions that are being established 50 50 00:02:10,710 --> 00:02:12,000 or trying to make connections. 51 51 00:02:12,000 --> 00:02:14,730 And then using analysis, we can correlate that 52 52 00:02:14,730 --> 00:02:16,380 into beaconing activity. 53 53 00:02:16,380 --> 00:02:18,480 Now here's a quick exam tip. 54 54 00:02:18,480 --> 00:02:20,520 For the exam, you are likely going to see 55 55 00:02:20,520 --> 00:02:22,050 an example of beaconing. 56 56 00:02:22,050 --> 00:02:24,030 If they give you a log example and you see 57 57 00:02:24,030 --> 00:02:26,790 something happening as a beacon, they're usually going to make 58 58 00:02:26,790 --> 00:02:29,550 it happen on a regular interval every three seconds, 59 59 00:02:29,550 --> 00:02:33,150 every five seconds, every 15 seconds, every day at midnight, 60 60 00:02:33,150 --> 00:02:36,180 something like that because that is traditional beaconing. 61 61 00:02:36,180 --> 00:02:39,450 But in the real world, most attackers aren't going to use 62 62 00:02:39,450 --> 00:02:41,670 the same time every single day. 63 63 00:02:41,670 --> 00:02:43,740 Instead, they will jump around using 64 64 00:02:43,740 --> 00:02:45,900 some sort of an algorithm or they'll switch up 65 65 00:02:45,900 --> 00:02:50,741 the IP or DNS names using DGA and fast flux DNS. 66 66 00:02:50,741 --> 00:02:52,320 Now as I said earlier, there are 67 67 00:02:52,320 --> 00:02:53,670 some legitimate applications 68 68 00:02:53,670 --> 00:02:56,310 that will also perform beaconing and this also makes 69 69 00:02:56,310 --> 00:02:58,440 it harder for us as defenders to identify 70 70 00:02:58,440 --> 00:03:02,400 what is malicious beaconing versus what is real beaconing. 71 71 00:03:02,400 --> 00:03:05,460 For example, a lot of legitimate applications 72 72 00:03:05,460 --> 00:03:09,090 like NTP servers, auto update and patching systems, 73 73 00:03:09,090 --> 00:03:12,540 and cluster services all use beaconing and heartbeats 74 74 00:03:12,540 --> 00:03:15,300 as a way for them to send out information and let 75 75 00:03:15,300 --> 00:03:18,990 other services know they are there and ready to support. 76 76 00:03:18,990 --> 00:03:21,360 So when you see something, you have to figure out is 77 77 00:03:21,360 --> 00:03:24,690 this malicious or is this something that's authorized? 78 78 00:03:24,690 --> 00:03:27,060 And as a defender, learning what normal, 79 79 00:03:27,060 --> 00:03:29,670 authorized behavior looks like within your network is 80 80 00:03:29,670 --> 00:03:32,190 key to start understanding what is malicious beaconing. 81 81 00:03:32,190 --> 00:03:34,620 Because if it's not something you've seen normally, 82 82 00:03:34,620 --> 00:03:37,860 it then becomes suspicious or malicious. 83 83 00:03:37,860 --> 00:03:40,110 Now as I said earlier, the adversaries are 84 84 00:03:40,110 --> 00:03:42,090 constantly trying to redevelop their techniques 85 85 00:03:42,090 --> 00:03:43,680 so they don't get caught. 86 86 00:03:43,680 --> 00:03:45,750 In the earlier days, they would use beaconing 87 87 00:03:45,750 --> 00:03:47,310 at consistent intervals. 88 88 00:03:47,310 --> 00:03:50,610 But to start avoiding detection, they started using DGAs 89 89 00:03:50,610 --> 00:03:54,180 and fast flux DNS and they started adding jitter. 90 90 00:03:54,180 --> 00:03:55,800 Now jitter is an adversary's use 91 91 00:03:55,800 --> 00:03:58,560 of a random delay to frustrate indicators based 92 92 00:03:58,560 --> 00:04:00,720 on regular connection attempt intervals. 93 93 00:04:00,720 --> 00:04:03,000 So if I used to see that this malware always connected 94 94 00:04:03,000 --> 00:04:08,000 at 3:15 AM, but now it may connect at 3:00, 3:15, 3:45, 95 95 00:04:08,340 --> 00:04:10,260 and it jumps around at different times using 96 96 00:04:10,260 --> 00:04:12,720 different delays, that's the idea of jitter. 97 97 00:04:12,720 --> 00:04:14,790 Now this jitter doesn't have to be a long period of time; 98 98 00:04:14,790 --> 00:04:16,500 it could just be a couple of milliseconds 99 99 00:04:16,500 --> 00:04:18,420 or a couple of seconds in either direction, 100 100 00:04:18,420 --> 00:04:21,600 but even that is going to be enough to confuse some sensors. 101 101 00:04:21,600 --> 00:04:23,820 Another way adversaries try to hide their activity 102 102 00:04:23,820 --> 00:04:27,180 of beaconing is they will start using sparse delivery. 103 103 00:04:27,180 --> 00:04:29,370 This allows them to reduce their packet sizes 104 104 00:04:29,370 --> 00:04:31,710 and, therefore, they can hide within the noise 105 105 00:04:31,710 --> 00:04:33,330 of other network traffic. 106 106 00:04:33,330 --> 00:04:35,190 If you're running a large network that's sending out 107 107 00:04:35,190 --> 00:04:38,070 gigabytes of data every single day, will you notice 108 108 00:04:38,070 --> 00:04:40,860 just a handful of packets being sent out as a beacon? 109 109 00:04:40,860 --> 00:04:42,030 Maybe or maybe not. 110 110 00:04:42,030 --> 00:04:43,410 It makes it a lot harder to find 111 111 00:04:43,410 --> 00:04:46,800 because it's that noise inside that larger signal. 112 112 00:04:46,800 --> 00:04:48,600 So now that we've talked a lot about beaconing 113 113 00:04:48,600 --> 00:04:50,820 in this lesson, you should understand what it is 114 114 00:04:50,820 --> 00:04:52,020 and why we use it. 115 115 00:04:52,020 --> 00:04:54,900 Because after all, a command and control server needs to be 116 116 00:04:54,900 --> 00:04:56,730 able to issue commands to its zombies 117 117 00:04:56,730 --> 00:04:58,890 as part of the botnet using some kind 118 118 00:04:58,890 --> 00:05:00,450 of a communication channel. 119 119 00:05:00,450 --> 00:05:02,880 Usually this is going to start out using a beacon 120 120 00:05:02,880 --> 00:05:04,530 and then it'll be able to send out 121 121 00:05:04,530 --> 00:05:07,290 additional control signals in response to those beacons 122 122 00:05:07,290 --> 00:05:09,270 if they need to send out an attack. 123 123 00:05:09,270 --> 00:05:10,717 Essentially, the beacon is just saying, 124 124 00:05:10,717 --> 00:05:12,960 "I'm here and I'm ready to receive orders." 125 125 00:05:12,960 --> 00:05:14,910 Then the command and control server needs to send 126 126 00:05:14,910 --> 00:05:16,380 information back to them. 127 127 00:05:16,380 --> 00:05:17,310 And how they do that is 128 128 00:05:17,310 --> 00:05:19,890 through various communication channels. 129 129 00:05:19,890 --> 00:05:22,320 These channels include things like internet relay chat, 130 130 00:05:22,320 --> 00:05:26,580 or IRC, HTTP and HTTPS connections, 131 131 00:05:26,580 --> 00:05:29,310 domain name system or DNS connections, 132 132 00:05:29,310 --> 00:05:32,370 social media websites, cloud services, 133 133 00:05:32,370 --> 00:05:34,380 and media and document files. 134 134 00:05:34,380 --> 00:05:35,760 Let's talk about each of these as we go 135 135 00:05:35,760 --> 00:05:37,200 through the rest of this lesson. 136 136 00:05:37,200 --> 00:05:41,220 First, let's talk about IRC, which is internet relay chat. 137 137 00:05:41,220 --> 00:05:43,920 This is a group communication protocol with networks divided 138 138 00:05:43,920 --> 00:05:46,170 into discreet channels that are then used 139 139 00:05:46,170 --> 00:05:49,770 as individual forums by the clients to chat with each other. 140 140 00:05:49,770 --> 00:05:53,040 Now IRC is basically the early version of chat. 141 141 00:05:53,040 --> 00:05:55,020 Think about it like Facebook Messenger 142 142 00:05:55,020 --> 00:05:57,720 or Discord or something like that. 143 143 00:05:57,720 --> 00:06:01,320 IRC was really popular back in the 90s and early 2000s. 144 144 00:06:01,320 --> 00:06:04,080 Essentially, you could log onto a different server 145 145 00:06:04,080 --> 00:06:06,210 and in that server, there'd be lots of different chat rooms 146 146 00:06:06,210 --> 00:06:08,370 and you could go in and start talking on those. 147 147 00:06:08,370 --> 00:06:10,860 Well over time, people developed bots that could run 148 148 00:06:10,860 --> 00:06:13,470 these chat rooms and they could also be used 149 149 00:06:13,470 --> 00:06:15,420 as a command and control mechanism. 150 150 00:06:15,420 --> 00:06:18,030 Now these days, most organizations don't have 151 151 00:06:18,030 --> 00:06:20,790 a legitimate use for IRC and because of that, 152 152 00:06:20,790 --> 00:06:24,060 most organizations will simply block IRC. 153 153 00:06:24,060 --> 00:06:25,800 This way, the use of IRC 154 154 00:06:25,800 --> 00:06:28,500 as a command and control channel is eliminated. 155 155 00:06:28,500 --> 00:06:30,270 And because of this, the use of IRC 156 156 00:06:30,270 --> 00:06:32,010 as a command and control channel has been 157 157 00:06:32,010 --> 00:06:34,470 on the decline for many years. 158 158 00:06:34,470 --> 00:06:37,200 So adversaries had to find another way 159 159 00:06:37,200 --> 00:06:41,730 and that brings us to our second method, HTTP and HTTPS. 160 160 00:06:41,730 --> 00:06:44,640 Now unlike IRC, every business has a need 161 161 00:06:44,640 --> 00:06:46,050 for web connections. 162 162 00:06:46,050 --> 00:06:48,210 You need to go to a website to pay your bills. 163 163 00:06:48,210 --> 00:06:49,830 You need to go to a website to sell things 164 164 00:06:49,830 --> 00:06:50,730 for your customers. 165 165 00:06:50,730 --> 00:06:52,380 You need to go to a website to set up 166 166 00:06:52,380 --> 00:06:53,940 your advertising campaigns. 167 167 00:06:53,940 --> 00:06:57,300 All of that runs on HTTP or HTTPS, 168 168 00:06:57,300 --> 00:07:00,540 which runs on either port 80 or port 443. 169 169 00:07:00,540 --> 00:07:03,390 Now these communications over these web protocols are 170 170 00:07:03,390 --> 00:07:06,540 a necessity in almost every organizational network 171 171 00:07:06,540 --> 00:07:09,060 so you can't just blanket and say we're not going to allow 172 172 00:07:09,060 --> 00:07:12,120 port 80 or port 443 traffic because you would shut down 173 173 00:07:12,120 --> 00:07:14,310 everything your business needs to run. 174 174 00:07:14,310 --> 00:07:16,980 So what can you do to prevent these from being used 175 175 00:07:16,980 --> 00:07:20,430 as a communications channel for the C2 servers? 176 176 00:07:20,430 --> 00:07:23,430 Well, the best mitigation is to use a intercepting proxy 177 177 00:07:23,430 --> 00:07:24,900 at your network's edge. 178 178 00:07:24,900 --> 00:07:27,720 Now this is also known as break and inspect. 179 179 00:07:27,720 --> 00:07:30,600 Essentially, you have a device at the edge of your network 180 180 00:07:30,600 --> 00:07:33,210 and when somebody internal to your network wants to connect 181 181 00:07:33,210 --> 00:07:36,690 to something like Gmail over a secure connection, 182 182 00:07:36,690 --> 00:07:39,240 they would go, instead of doing a connection between them 183 183 00:07:39,240 --> 00:07:42,780 and Gmail with an HTTPS tunnel, they instead would connect 184 184 00:07:42,780 --> 00:07:45,240 from them to this intercepting proxy 185 185 00:07:45,240 --> 00:07:47,730 and then the intercepting proxy makes a secure connection 186 186 00:07:47,730 --> 00:07:49,320 out to the Gmail server. 187 187 00:07:49,320 --> 00:07:51,420 This way, you end up having a secure tunnel 188 188 00:07:51,420 --> 00:07:54,000 all the way across, but you're essentially an authorized 189 189 00:07:54,000 --> 00:07:56,700 on-path attacker with you sitting at that network edge. 190 190 00:07:56,700 --> 00:07:58,800 This allows your network defenders to analyze 191 191 00:07:58,800 --> 00:08:00,510 the traffic going in and out of your network 192 192 00:08:00,510 --> 00:08:03,090 within those HTTPS connections. 193 193 00:08:03,090 --> 00:08:05,520 Our third type of communication channel that's used heavily 194 194 00:08:05,520 --> 00:08:09,870 by C2 networks is DNS or the domain name system. 195 195 00:08:09,870 --> 00:08:13,140 Now most DNS traffic is not inspected or filtered 196 196 00:08:13,140 --> 00:08:16,140 in private organizational networks so attackers have found 197 197 00:08:16,140 --> 00:08:19,200 DNS to be an effective command and control channel. 198 198 00:08:19,200 --> 00:08:20,100 Now another reason this is 199 199 00:08:20,100 --> 00:08:22,140 an effective command and control channel is 200 200 00:08:22,140 --> 00:08:24,060 that you don't actually have to have a direct connection 201 201 00:08:24,060 --> 00:08:27,150 to the outside network to be able to send out a signal. 202 202 00:08:27,150 --> 00:08:30,330 Instead, you could send it to your local DNS resolver. 203 203 00:08:30,330 --> 00:08:33,270 That local DNS resolver will then execute the lookup 204 204 00:08:33,270 --> 00:08:36,060 on the authorative servers outside the organization, 205 205 00:08:36,060 --> 00:08:38,610 like on the internet, and then they'll receive the response 206 206 00:08:38,610 --> 00:08:40,260 with a control message. 207 207 00:08:40,260 --> 00:08:42,420 Now this allows attackers to send their commands 208 208 00:08:42,420 --> 00:08:44,880 in either a request or response query. 209 209 00:08:44,880 --> 00:08:46,710 So if I'm trying to do something as a beacon out, 210 210 00:08:46,710 --> 00:08:49,440 I can send it out as a malicious host sending 211 211 00:08:49,440 --> 00:08:51,900 out the request, and then if I want to send a command back, 212 212 00:08:51,900 --> 00:08:54,810 I can send that back as part of the response query. 213 213 00:08:54,810 --> 00:08:57,840 This way information can pass back and forth to that host, 214 214 00:08:57,840 --> 00:08:59,700 and again, it usually will bypass 215 215 00:08:59,700 --> 00:09:01,830 any inspection and any filtering. 216 216 00:09:01,830 --> 00:09:04,620 So how do you know if it's legitimate DNS traffic 217 217 00:09:04,620 --> 00:09:07,020 or if it's an indicator of compromise? 218 218 00:09:07,020 --> 00:09:09,050 Well, the first thing that might show that it's an indicator 219 219 00:09:09,050 --> 00:09:10,890 or compromise is if you start seeing 220 220 00:09:10,890 --> 00:09:13,560 the same query being repeated several times 221 221 00:09:13,560 --> 00:09:14,640 when a bot is checking 222 222 00:09:14,640 --> 00:09:16,920 into a control server for more orders. 223 223 00:09:16,920 --> 00:09:20,010 Essentially, a normal DNS query will happen once 224 224 00:09:20,010 --> 00:09:22,830 and you may not make that query again for several days. 225 225 00:09:22,830 --> 00:09:25,080 But if you see the same query being repeated 226 226 00:09:25,080 --> 00:09:27,450 every couple hours or every day or two, 227 227 00:09:27,450 --> 00:09:30,870 that could be an indicator that it is a bot checking in. 228 228 00:09:30,870 --> 00:09:33,720 Another indicator could be if you start seeing commands sent 229 229 00:09:33,720 --> 00:09:35,970 within a request or response query. 230 230 00:09:35,970 --> 00:09:38,430 And when you see this, it's usually because those requests 231 231 00:09:38,430 --> 00:09:40,110 and response queries will be longer 232 232 00:09:40,110 --> 00:09:42,330 and more complicated than normal. 233 233 00:09:42,330 --> 00:09:44,520 Now one of the ways that attackers actually send 234 234 00:09:44,520 --> 00:09:47,250 out information as part of these request to response is 235 235 00:09:47,250 --> 00:09:49,740 they're actually going to send out more data inside that packet 236 236 00:09:49,740 --> 00:09:51,720 so they can send the commands they want to send. 237 237 00:09:51,720 --> 00:09:53,730 So instead of just saying, "What is the address 238 238 00:09:53,730 --> 00:09:56,550 for diontraining.com?", they may say "What is the address 239 239 00:09:56,550 --> 00:09:58,920 for diontraining.com and here's all this other command 240 240 00:09:58,920 --> 00:09:59,850 and control information." 241 241 00:09:59,850 --> 00:10:01,650 So you'll see a larger packet size 242 242 00:10:01,650 --> 00:10:04,200 or longer and more complicated requests. 243 243 00:10:04,200 --> 00:10:07,230 Now with this second IOC, though, one of the ways 244 244 00:10:07,230 --> 00:10:09,870 that they can evade detection is actually breaking up 245 245 00:10:09,870 --> 00:10:13,020 their control messages into several query chunks to help 246 246 00:10:13,020 --> 00:10:14,340 not trip the sensors. 247 247 00:10:14,340 --> 00:10:17,040 So instead of having this one really big DNS request, 248 248 00:10:17,040 --> 00:10:20,040 they can have that DNS request chopped into smaller packets 249 249 00:10:20,040 --> 00:10:23,250 and by doing that, they will be able to evade detection. 250 250 00:10:23,250 --> 00:10:25,350 Again, though, if you can take that traffic 251 251 00:10:25,350 --> 00:10:27,450 and put it back together, you can then see 252 252 00:10:27,450 --> 00:10:29,190 what the larger request was 253 253 00:10:29,190 --> 00:10:31,560 and see what malicious intent they had. 254 254 00:10:31,560 --> 00:10:34,470 Our next category is social media websites. 255 255 00:10:34,470 --> 00:10:37,530 Sites like Facebook and Twitter and LinkedIn have all been 256 256 00:10:37,530 --> 00:10:40,800 vectors for command and control operations in the past. 257 257 00:10:40,800 --> 00:10:42,840 This is because as people have started blocking things 258 258 00:10:42,840 --> 00:10:45,690 like internet relay chat, more people have moved to things 259 259 00:10:45,690 --> 00:10:48,570 like Facebook and Twitter and LinkedIn for messaging. 260 260 00:10:48,570 --> 00:10:50,370 Another reason the attackers use this is 261 261 00:10:50,370 --> 00:10:52,440 because by using these social media platforms 262 262 00:10:52,440 --> 00:10:54,120 messaging functions, this allows 263 263 00:10:54,120 --> 00:10:55,920 the attacker to live off the land. 264 264 00:10:55,920 --> 00:10:57,360 They don't have to create their own tools. 265 265 00:10:57,360 --> 00:11:00,120 They can just send messages through their APIs 266 266 00:11:00,120 --> 00:11:02,250 and that way they don't have to install anything 267 267 00:11:02,250 --> 00:11:04,470 and it makes it harder for you to detect them. 268 268 00:11:04,470 --> 00:11:07,230 For example, there was one case where a botnet was using 269 269 00:11:07,230 --> 00:11:09,930 LinkedIn as its command and control platform. 270 270 00:11:09,930 --> 00:11:12,750 Essentially, what would happen is these bots would check 271 271 00:11:12,750 --> 00:11:16,350 LinkedIn every day and if they saw that the job position 272 272 00:11:16,350 --> 00:11:18,930 for a particular contact was changed, for instance, 273 273 00:11:18,930 --> 00:11:20,160 it went from the accounting department 274 274 00:11:20,160 --> 00:11:21,930 to the human resources department, 275 275 00:11:21,930 --> 00:11:25,110 that would be the signal to now do their attack payloads. 276 276 00:11:25,110 --> 00:11:26,610 And so that was the way they used 277 277 00:11:26,610 --> 00:11:28,380 this way to send out a command. 278 278 00:11:28,380 --> 00:11:30,930 It was very sneaky and it worked really well 279 279 00:11:30,930 --> 00:11:34,140 because a lot of companies trusted LinkedIn. 280 280 00:11:34,140 --> 00:11:36,270 And so when they saw something like a field 281 281 00:11:36,270 --> 00:11:38,280 like employment status or employment history 282 282 00:11:38,280 --> 00:11:39,450 or a status update, 283 283 00:11:39,450 --> 00:11:43,050 that could trigger some sort of action by this malware. 284 284 00:11:43,050 --> 00:11:45,150 Another example is Twitter. 285 285 00:11:45,150 --> 00:11:48,060 There was another botnet out there that used hashtags 286 286 00:11:48,060 --> 00:11:49,590 as part of the command strings 287 287 00:11:49,590 --> 00:11:51,240 that they were sending to the bots. 288 288 00:11:51,240 --> 00:11:53,100 Essentially, the way this worked is the bots 289 289 00:11:53,100 --> 00:11:55,380 on the victim machine would look at Twitter 290 290 00:11:55,380 --> 00:11:57,870 and whenever they saw messages with a certain hashtag, 291 291 00:11:57,870 --> 00:12:00,030 they would then use that, parse that message, 292 292 00:12:00,030 --> 00:12:02,820 and use that as the way to receive their orders. 293 293 00:12:02,820 --> 00:12:06,600 Our fourth type of communication channel is cloud services. 294 294 00:12:06,600 --> 00:12:08,760 Cloud services are great for an attacker 295 295 00:12:08,760 --> 00:12:10,710 because they don't have to own their own services 296 296 00:12:10,710 --> 00:12:12,150 and own their own servers. 297 297 00:12:12,150 --> 00:12:14,490 Instead, they can spin up virtual machines 298 298 00:12:14,490 --> 00:12:18,420 or use app-based engines to be able to send out C2 messages. 299 299 00:12:18,420 --> 00:12:20,880 For example, attackers in the past have used 300 300 00:12:20,880 --> 00:12:22,620 Google's app engine platform to send 301 301 00:12:22,620 --> 00:12:24,030 command and control messages 302 302 00:12:24,030 --> 00:12:27,330 through a hosted custom application within that platform. 303 303 00:12:27,330 --> 00:12:29,970 Others have used things like AWS Lambda to use 304 304 00:12:29,970 --> 00:12:32,100 those type of functions, as well, and this way, 305 305 00:12:32,100 --> 00:12:33,840 they don't have to incur the cost of setting up 306 306 00:12:33,840 --> 00:12:36,450 their own servers and they can use the cloud company's 307 307 00:12:36,450 --> 00:12:38,970 reliable and scalable infrastructure to send out 308 308 00:12:38,970 --> 00:12:41,130 those messages to a very large audience 309 309 00:12:41,130 --> 00:12:42,870 of bots in their control. 310 310 00:12:42,870 --> 00:12:45,120 The final communication channel we need to talk about is 311 311 00:12:45,120 --> 00:12:48,540 metadata, which exists within media and document files. 312 312 00:12:48,540 --> 00:12:51,690 Now metadata is a set of data that describes information 313 313 00:12:51,690 --> 00:12:53,250 about other data. 314 314 00:12:53,250 --> 00:12:55,860 Now for instance, if you're looking at an MP3 file 315 315 00:12:55,860 --> 00:13:00,180 or a PNG file or a JPEG or an MP4 or anything; 316 316 00:13:00,180 --> 00:13:03,570 it can be audio or video or images, all of these have 317 317 00:13:03,570 --> 00:13:06,120 metadata embedded within those files. 318 318 00:13:06,120 --> 00:13:08,460 Now the metadata within these files can hold 319 319 00:13:08,460 --> 00:13:10,860 attackers' command and control messages, too. 320 320 00:13:10,860 --> 00:13:13,830 And so when you actually send a message to that network 321 321 00:13:13,830 --> 00:13:16,950 like, "Here is a PNG file," which is a graphic file 322 322 00:13:16,950 --> 00:13:19,830 as part of an email, the bot could read that message, 323 323 00:13:19,830 --> 00:13:23,550 read the metadata off that PNG file, off that graphic file, 324 324 00:13:23,550 --> 00:13:27,270 and that would then tell them, execute X-Y-Z attack method. 325 325 00:13:27,270 --> 00:13:30,510 This way, that metadata holds the C2 messages 326 326 00:13:30,510 --> 00:13:32,610 and it can get through your detection systems 327 327 00:13:32,610 --> 00:13:35,040 because your detection systems probably aren't looking 328 328 00:13:35,040 --> 00:13:37,293 inside the metadata of these different files.