WEBVTT 0:00:03.760000 --> 0:00:06.420000 Network file carving with wire shark. 0:00:06.420000 --> 0:00:07.560000 So welcome everyone. 0:00:07.560000 --> 0:00:12.100000 In this video, we're gonna be taking a look at how to carve files from 0:00:12.100000 --> 0:00:14.760000 network traffic using wire shark. 0:00:14.760000 --> 0:00:19.580000 So before we even get to the practical demonstration section of this video, 0:00:19.580000 --> 0:00:24.420000 I need to explain a little bit about what network file carving is all 0:00:24.420000 --> 0:00:29.160000 about. So network file carving is the process of extracting files from 0:00:29.160000 --> 0:00:32.800000 raw network traffic captures, typically in PCAP format. 0:00:32.800000 --> 0:00:37.200000 Now you may be thinking to yourself, we did this in the previous video. 0:00:37.200000 --> 0:00:45.620000 Yes, we did, but that was not really representative of what a PCAP that 0:00:45.620000 --> 0:00:47.880000 you've been told to investigate would look like. 0:00:47.880000 --> 0:00:50.640000 And don't worry if that doesn't make sense right now. 0:00:50.640000 --> 0:00:52.680000 It will in a few seconds. 0:00:52.680000 --> 0:00:57.820000 But continuing on, it allows incident responders and forensic analysts 0:00:57.820000 --> 0:01:00.060000 to reconstruct files. 0:01:00.060000 --> 0:01:01.640000 That's the key word here. 0:01:01.640000 --> 0:01:05.100000 That were transferred across the network often without needing access 0:01:05.100000 --> 0:01:07.260000 to the original endpoints. 0:01:07.260000 --> 0:01:11.820000 So building on top of that, how does network file carving work? 0:01:11.820000 --> 0:01:18.200000 So when files are transferred over protocols like HTTP, FTP, SMB or SMTP, 0:01:18.200000 --> 0:01:22.060000 the file contents are usually embedded within the network packets. 0:01:22.060000 --> 0:01:26.300000 By analyzing and reassembling those packets, you can quote unquote carve 0:01:26.300000 --> 0:01:28.560000 out the complete file. 0:01:28.560000 --> 0:01:33.680000 Now when is this commonly used in all, what type of incidents would you 0:01:33.680000 --> 0:01:40.000000 usually require you to perform some form of network file carving? 0:01:40.000000 --> 0:01:45.800000 Well, think of incidents that involve download of malware. 0:01:45.800000 --> 0:01:51.760000 So in the case of malware analysis, network file carving allows you to 0:01:51.760000 --> 0:01:59.040000 extract malicious payloads or drive by downloads data exfiltration investigations 0:01:59.040000 --> 0:02:03.900000 in that you can recover files and attack a cent out of the network. 0:02:03.900000 --> 0:02:09.800000 And for intrusion analysis, you can identify unauthorized file transfers 0:02:09.800000 --> 0:02:12.020000 or dropped files. 0:02:12.020000 --> 0:02:18.280000 Okay, so the idea is, I'll use a particular example if you're told to 0:02:18.280000 --> 0:02:24.780000 investigate a PCAP or investigate an incident where a specific user within 0:02:24.780000 --> 0:02:30.940000 an organization downloaded a file, PDF document, et cetera, it really 0:02:30.940000 --> 0:02:36.420000 doesn't matter. But that file was the source of an intrusion. 0:02:36.420000 --> 0:02:42.140000 You would essentially need to, if you're not performing or analyzing the 0:02:42.140000 --> 0:02:46.260000 file on the endpoint for whatever reason, you can easily utilize network 0:02:46.260000 --> 0:02:51.680000 file carving if traffic was captured to again, carve out the complete 0:02:51.680000 --> 0:02:56.060000 file and then analyze it further. 0:02:56.060000 --> 0:03:02.000000 But this is an example of a common scenario that you'll usually find yourself 0:03:02.000000 --> 0:03:08.400000 dealing with, specifically in relation to analyzing PCAPs. 0:03:08.400000 --> 0:03:11.960000 So this video has a lab associated with it. 0:03:11.960000 --> 0:03:16.060000 The lab is just going to be below this video and it's aptly named network 0:03:16.060000 --> 0:03:20.360000 file carving. It doesn't have the suffix with wire shocks, so it's just 0:03:20.360000 --> 0:03:22.100000 called network file carving. 0:03:22.100000 --> 0:03:26.080000 In any case, I'm going to fire up the lab environment and I'll see you 0:03:26.080000 --> 0:03:29.840000 in the lab environment in a couple of seconds. 0:03:29.840000 --> 0:03:33.140000 All right, so I'm currently within the lab environment and as documented 0:03:33.140000 --> 0:03:38.860000 in the lab tasks section, we have three tasks. 0:03:38.860000 --> 0:03:43.920000 First is to identify the protocol and the domain through which the file 0:03:43.920000 --> 0:03:46.560000 was downloaded using wire shock. 0:03:46.560000 --> 0:03:51.000000 So the PCAP in question can be found on the desktop under module seven 0:03:51.000000 --> 0:03:58.460000 and lab 20 right over here and the name of the PCAP is file carving right 0:03:58.460000 --> 0:04:02.080000 over here, S0 I0.PCAP. 0:04:02.080000 --> 0:04:05.180000 So we can open this with wire shock directly. 0:04:05.180000 --> 0:04:08.840000 That's exactly what I'm going to do and I'll just zoom in a little bit 0:04:08.840000 --> 0:04:12.460000 here and we can get started. 0:04:12.460000 --> 0:04:20.140000 So the first thing we can do is open up here to see what we're dealing 0:04:20.140000 --> 0:04:27.900000 with. And the idea is to sort of identify what a protocol specific to 0:04:27.900000 --> 0:04:33.240000 this particular PCAP has the most amount of traffic or has an anomalous 0:04:33.240000 --> 0:04:35.400000 amount of traffic, right? 0:04:35.400000 --> 0:04:41.800000 So for example, under TCP, we can see HTTP, there's nothing, so percent 0:04:41.800000 --> 0:04:45.500000 bytes, percent back packets. 0:04:45.500000 --> 0:04:48.880000 Yeah, if we sort this, it looks like we're dealing with a lot of HTTP 0:04:48.880000 --> 0:05:00.140000 data here. So what we can do from this point is, if we just close this 0:05:00.140000 --> 0:05:05.700000 up and we go into statistics and we take a look at the HTTP requests made 0:05:05.700000 --> 0:05:11.020000 in terms of stats, we can see that there's a couple here and what we want 0:05:11.020000 --> 0:05:15.620000 to do firstly is identify as per the task requirements, the protocol and 0:05:15.620000 --> 0:05:18.360000 domain through which the file was downloaded. 0:05:18.360000 --> 0:05:23.280000 So what was communicated to us again, if we were to analyze this as we 0:05:23.280000 --> 0:05:29.880000 would, a ticket or a case, an instant that we've been asked to investigate, 0:05:29.880000 --> 0:05:33.500000 the filing question was a PDF, so we can see it right here. 0:05:33.500000 --> 0:05:38.820000 It was downloaded from Fujitsu.com and from the following endpoint, or 0:05:38.820000 --> 0:05:46.040000 URL, so URI, I should say, so downloads, tell, FNC, PDF services, TCP, 0:05:46.040000 --> 0:05:50.720000 IP, tutorials. So that's the malicious PDF in question, or the one that 0:05:50.720000 --> 0:05:53.440000 we were told to sort of analyze. 0:05:53.440000 --> 0:05:59.380000 So the objective here now, we've grown through task one, so the next step 0:05:59.380000 --> 0:06:04.140000 now is to extract the downloaded file using a wire shock. 0:06:04.140000 --> 0:06:08.920000 So in order to extract the downloaded file, we need to find the network 0:06:08.920000 --> 0:06:13.060000 streams which contain that particular file, in this case the PDF and extract 0:06:13.060000 --> 0:06:16.300000 those bytes, that's one technique, right? 0:06:16.300000 --> 0:06:19.900000 Into an independent file that we can access later. 0:06:19.900000 --> 0:06:24.380000 So one way to look for the file or to search for the file is using its 0:06:24.380000 --> 0:06:31.460000 magic number or its header, the file type header, in this case the PDF 0:06:31.460000 --> 0:06:39.020000 header. So we know that we're dealing with a PDF file, so we can actually, 0:06:39.020000 --> 0:06:46.060000 now that we know the file type, we can actually use that to our advantage 0:06:46.060000 --> 0:06:52.100000 and look for the PDF signature within the PDF HTTP stream, and we can 0:06:52.100000 --> 0:07:00.000000 do this by closing this up and using a display filter and say HTTP contains, 0:07:00.000000 --> 0:07:04.680000 and we say PDF, okay, and we hit enter, and there we are, we have the 0:07:04.680000 --> 0:07:09.200000 packet associated with the PDF. 0:07:09.200000 --> 0:07:14.660000 So we can now, now that we've found the packet in question, we can actually 0:07:14.660000 --> 0:07:20.120000 utilize the wire shock extraction feature to dump those bytes, the raw 0:07:20.120000 --> 0:07:27.420000 bytes, into a file, so we can right click here, and that's one way you, 0:07:27.420000 --> 0:07:31.660000 of course, you already know about the other way, but we can go into file 0:07:31.660000 --> 0:07:40.780000 and let's go to export, sorry, packet bytes right over here. 0:07:40.780000 --> 0:07:50.380000 And now, let's see, did it actually save it one second? 0:07:50.380000 --> 0:07:54.660000 It should actually, we should be able to, one second, let me just make 0:07:54.660000 --> 0:08:00.620000 sure I've highlighted it here, so file highlight export, yeah, packet 0:08:00.620000 --> 0:08:09.580000 to bytes. My bad, we actually have to specify what we want to export to 0:08:09.580000 --> 0:08:12.960000 bytes, so make sure you highlight that in the packet details pane, and 0:08:12.960000 --> 0:08:18.340000 then we say export packet, export packet bytes, we'll save it on the desktop, 0:08:18.340000 --> 0:08:23.960000 so you can now, you can save it as a bin file, so we'll just call it PDF, 0:08:23.960000 --> 0:08:26.720000 actually hold on file. 0:08:26.720000 --> 0:08:30.540000 Yeah, we'll just say bin, and then you can always rename it, so let's 0:08:30.540000 --> 0:08:35.580000 see if we've actually done this successfully, so there we are, file, and 0:08:35.580000 --> 0:08:40.240000 we can say open with QPDF view, in fact, yeah, we might not need to do 0:08:40.240000 --> 0:08:44.580000 that, and there we have the entire, you know, I know that this is sort 0:08:44.580000 --> 0:08:48.340000 of fictitious, but this would be the malicious PDF, and obviously you 0:08:48.340000 --> 0:08:51.440000 would not execute it immediately, regardless as to whether you're using 0:08:51.440000 --> 0:08:56.600000 your analysis system or your analyst system to do so, but this would be, 0:08:56.600000 --> 0:09:00.540000 you know, what we would then analyze or pass through a malware analysis, 0:09:00.540000 --> 0:09:04.140000 for example. Now there's also the other technique, which we explored in 0:09:04.140000 --> 0:09:09.080000 the previous video, and that is to, you know, to go file, and then export 0:09:09.080000 --> 0:09:15.340000 objects, and in this case it's HTTP, and here we can look for less filter 0:09:15.340000 --> 0:09:21.700000 by size, so largest first, so there we application PDF, save, and now 0:09:21.700000 --> 0:09:26.920000 we get, we'll save it on the desktop there, save it there, okay, beautiful, 0:09:26.920000 --> 0:09:32.920000 and now we have it here, so same PDF, but now just save it with its appropriate 0:09:32.920000 --> 0:09:39.680000 name. So that's, you know, the most basic type of file carving, so you 0:09:39.680000 --> 0:09:42.580000 can use that particular technique if you wish. 0:09:42.580000 --> 0:09:46.520000 Now there's the third task, you know, for this lab, which is to examine 0:09:46.520000 --> 0:09:51.940000 the second PCAP, and extract the downloaded file from it, so there's another 0:09:51.940000 --> 0:09:56.740000 PCAP that we need to analyze here, so I'm just going to close this up, 0:09:56.740000 --> 0:10:02.120000 and we want to go to module seven, lab20 and file2.PCAP, that's the one, 0:10:02.120000 --> 0:10:05.000000 so we'll open this up in a while, shark as well. 0:10:05.000000 --> 0:10:11.100000 There we are, now we're dealing with, you know, a little bit more of an 0:10:11.100000 --> 0:10:16.300000 interesting PCAP, so we'll go again into the protocol hierarchy statistics, 0:10:16.300000 --> 0:10:20.480000 and let's see whether we can identify it and normally here in terms of, 0:10:20.480000 --> 0:10:26.480000 you know, percentage packets in, out, and this one looks interesting, 0:10:26.480000 --> 0:10:32.320000 so ICMP, okay, so there's a lot of ICMP traffic, now this is definitely 0:10:32.320000 --> 0:10:36.840000 suspicious, especially given the use of ICMP on a network, or what the 0:10:36.840000 --> 0:10:43.400000 protocol is used for, so, you know, we can actually, if we close this 0:10:43.400000 --> 0:10:51.000000 up, let me just, we have, so this we also have MAC addresses here, which 0:10:51.000000 --> 0:10:57.180000 is interesting, so this is definitely captured on a network, so we can 0:10:57.180000 --> 0:11:04.060000 see ICMP right over here, and yeah, interesting, very, very interesting, 0:11:04.060000 --> 0:11:10.260000 so we have the echo ping request, so let's take a look at this, the data, 0:11:10.260000 --> 0:11:19.340000 oh, 320 bytes, very interesting, so this is the data here, okay, so this 0:11:19.340000 --> 0:11:24.360000 is quite a bit of info, and it looks like some very interesting information 0:11:24.360000 --> 0:11:34.600000 is contained therein, now what we can obviously do is, in order to sort 0:11:34.600000 --> 0:11:39.300000 of understand what was being sent, just told, yeah, we can see a PDF header 0:11:39.300000 --> 0:11:42.880000 right over here as well, that's very, very interesting, so it looks like 0:11:42.880000 --> 0:11:51.940000 a PDF, you know, was sent here via ICMP, so, you know, we just, let's 0:11:51.940000 --> 0:11:55.860000 take a look at the first one, you know, we can see that the data section 0:11:55.860000 --> 0:11:59.540000 is actually much larger than usual, this, you know, you're not expect 0:11:59.540000 --> 0:12:06.220000 to see 320 bytes being sent, so, and the reason for that is because, with 0:12:06.220000 --> 0:12:10.620000 ICMP, you typically expect, you know, ping request and reply, so it's 0:12:10.620000 --> 0:12:14.220000 usually very, very small, the data contained therein is, again, very, 0:12:14.220000 --> 0:12:20.600000 very small, so we just saw the header here, the file type header PDF, 0:12:20.600000 --> 0:12:27.120000 right, or, you know, the PDF string right over here, so 1.6, let's take 0:12:27.120000 --> 0:12:32.340000 a look whether we have anything at 1.6, yeah, which pretty much tells 0:12:32.340000 --> 0:12:36.720000 us that there's a PDF file that has probably been embedded within the 0:12:36.720000 --> 0:12:42.640000 ICMP packets, so in order for us to, you know, extract ICMP payloads, 0:12:42.640000 --> 0:12:47.780000 we need to use a tool like T-Shock to make it a little bit easier, so 0:12:47.780000 --> 0:12:52.980000 what we can do is open up a terminal right over here, and what we're going 0:12:52.980000 --> 0:13:00.260000 to say now is T-Shock, T-Shock, if I can type it in correctly and specify 0:13:00.260000 --> 0:13:07.860000 the path to the PCAP, so this is a desktop module seven, lab 20, if I 0:13:07.860000 --> 0:13:17.080000 remember, correctly, lab 20, and the PCAP will just file 2.PCAP, and then 0:13:17.080000 --> 0:13:23.560000 we're going to save, you know, ICMP filter, ICMP, and then we're going 0:13:23.560000 --> 0:13:34.000000 to say T fields and E data, and we're going to save that to, we'll just 0:13:34.000000 --> 0:13:39.320000 call it ICMP data.txt, okay? 0:13:39.320000 --> 0:13:47.960000 Okay, that's done, so we have extracted all ICMP packet payloads into 0:13:47.960000 --> 0:13:53.720000 this text file here, which I saved in the home directory of the root user, 0:13:53.720000 --> 0:13:59.480000 but if we open this up, you'll realize that this is in hex format, which 0:13:59.480000 --> 0:14:03.880000 means we also need to convert it, we can probably convert it into a binary, 0:14:03.880000 --> 0:14:11.920000 so what we can do now is say, or utilize, we have XXD here, there we are, 0:14:11.920000 --> 0:14:18.020000 so make a hex dump or do the reverse, so we can actually say XXD, R, and 0:14:18.020000 --> 0:14:26.980000 then E ICMP data.txt, and we can just call it ICMP extracted, and because 0:14:26.980000 --> 0:14:33.680000 it's a bin or binary bin, really, in terms of the file format, so this 0:14:33.680000 --> 0:14:39.460000 is a binary, so we just hit enter, and now we have ICMP extracted or bin 0:14:39.460000 --> 0:14:45.780000 there, so what this means is that ICMP extracted or bin will contain all 0:14:45.780000 --> 0:14:55.020000 the raw ICMP payloads that, you know, not encoded in hex, so what we can 0:14:55.020000 --> 0:15:00.280000 now do to, you know, push out what we take our analysis further is, you 0:15:00.280000 --> 0:15:06.920000 know, you know, try and analyze the bin or, you know, we've pretty much 0:15:06.920000 --> 0:15:12.360000 extracted it into a bin, which we can now, you know, transpose, and if 0:15:12.360000 --> 0:15:18.180000 we open up, you can see ICMP extracted dot bin, hold on a second, oh, 0:15:18.180000 --> 0:15:21.980000 I don't think we can access that, let's try. 0:15:21.980000 --> 0:15:31.100000 Interesting, what if we changed this ICMP extracted, would we need the 0:15:31.100000 --> 0:15:39.160000 header here, let's say, we can actually confirm it just a second, so I'll 0:15:39.160000 --> 0:15:44.780000 just do that one more time, so we'll just convert that using XXD. 0:15:44.780000 --> 0:15:51.560000 Now, if we, I don't think there was a little bit, there probably is a 0:15:51.560000 --> 0:15:56.780000 legitimate PDF, but we can confirm it using the file utility, so we're 0:15:56.780000 --> 0:16:03.200000 gonna say ICMP extracted dot bin, there we are, we can actually confirm 0:16:03.200000 --> 0:16:09.780000 it, so PDF document version 1.6, and it has seven pages, now obviously, 0:16:09.780000 --> 0:16:18.060000 one second, so we go in here, rename, I wonder whether giving it the extension 0:16:18.060000 --> 0:16:26.120000 would allow us to access it, yeah, probably not, let me say open with, 0:16:26.120000 --> 0:16:36.400000 hold on, so let me go ahead and say, cat ICMP extracted dot bin, yeah, 0:16:36.400000 --> 0:16:41.400000 this actually would not need a lot of modification in order to, you know, 0:16:41.400000 --> 0:16:48.500000 turn it into a PDF, one second, we have the header there, just to confirm, 0:16:48.500000 --> 0:16:53.800000 I probably can't analyze it like this, yeah, but I'm seeing some interesting 0:16:53.800000 --> 0:17:05.460000 info here, so I just extracted the strings, and from the ICMP extracted 0:17:05.460000 --> 0:17:11.860000 dot bin file, and you can see it has the PDF header there, and yeah, this 0:17:11.860000 --> 0:17:17.600000 is definitely a PDF, and you know, the strings, I just use the strings 0:17:17.600000 --> 0:17:22.420000 utility to get that there, you can see the create is acrobat PDF maker 0:17:22.420000 --> 0:17:27.800000 8.1 for Word, not sure why we can't open it with the current PDF viewer, 0:17:27.800000 --> 0:17:33.960000 yeah, but these are just strings, remember, so I'm just going to quit 0:17:33.960000 --> 0:17:38.780000 from Vim, so you can utilize the strings utility, so you can say strings 0:17:38.780000 --> 0:17:47.740000 icmp extracted dot bin, and you can then just pipe that or save it redirected 0:17:47.740000 --> 0:17:53.060000 to file like strings dot txt, so that brings us to the end of the practical 0:17:53.060000 --> 0:17:56.060000 demonstration section of this video. 0:17:56.060000 --> 0:18:00.820000 All right, so that was network file calving with wire shock, hopefully 0:18:00.820000 --> 0:18:05.180000 you found that interesting, and you sort of understanding the amount of 0:18:05.180000 --> 0:18:11.280000 data, contained in a PCAP, or potentially contained in a PCAP, and we 0:18:11.280000 --> 0:18:15.680000 went through a workflow that you typically go through when you're analyzing 0:18:15.680000 --> 0:18:21.480000 a PCAP, and in this case, trying to extract some malicious files that 0:18:21.480000 --> 0:18:25.860000 were downloaded, or source of an intrusion or a malware infection, and 0:18:25.860000 --> 0:18:30.860000 of course this would require further or additional analysis, but with 0:18:30.860000 --> 0:18:34.720000 that being said, that brings us to the end of this video, in the next 0:18:34.720000 --> 0:18:38.960000 set of videos, we're going to still be using wire shock to analyze PCAPs, 0:18:38.960000 --> 0:18:43.180000 but we're now going to be looking for network specific activity, like 0:18:43.180000 --> 0:18:49.840000 analyzing network scans, analyzing network attacks, so things that are 0:18:49.840000 --> 0:18:52.880000 much closer to home with regards to instant response. 0:18:52.880000 --> 0:18:56.540000 In any case, that's going to be it for this video, and I will be seeing 0:18:56.540000 --> 0:18:58.200000 you in the next video.