WEBVTT 00:00:00.440 --> 00:00:01.650 In this demonstration, 00:00:01.670 --> 00:00:04.290 we'll take a look at reviewing scan results and 00:00:04.300 --> 00:00:06.260 initiating different types of searches. 00:00:07.240 --> 00:00:10.260 In our previous demo, we kicked off a simple scan. 00:00:10.740 --> 00:00:13.760 We will look at those results and the scan report interface. 00:00:14.240 --> 00:00:18.460 Spiderfoot has a method for marking false positives, which we'll examine. 00:00:19.240 --> 00:00:21.660 We'll also look at the options for different scans, 00:00:21.710 --> 00:00:23.760 starting with the idea of seed targets, 00:00:24.020 --> 00:00:27.100 the use cases we might utilize, and the various data 00:00:27.100 --> 00:00:29.260 types that Spiderfoot processes. 00:00:30.240 --> 00:00:32.159 Let's take a look at our previous scan. 00:00:34.140 --> 00:00:36.910 Our First Scan was a contrived scan looking at the 00:00:36.910 --> 00:00:39.450 test@example.com email address. 00:00:39.840 --> 00:00:42.760 Be aware that example.com was created by the Internet 00:00:42.760 --> 00:00:45.150 Assigned Numbers Authority for uses like this. 00:00:45.540 --> 00:00:48.750 There shouldn't be anyone using test@example.com. 00:00:49.140 --> 00:00:52.460 However, we can see that there are some results from that scan. 00:00:52.840 --> 00:00:56.790 To examine those results, click on the scan name. Here the 00:00:56.790 --> 00:00:58.860 scan results are grouped by data type. 00:00:59.640 --> 00:01:03.940 Let's look at the first data type, Account on External Site. 00:01:03.940 --> 00:01:09.610 Here we can see that the sfp_accounts module has identified a 00:01:09.610 --> 00:01:12.350 couple of accounts for bcautomation. 00:01:13.840 --> 00:01:14.950 I bet you're thinking, wait, 00:01:15.640 --> 00:01:19.410 weren't we looking for test@example.com? That's correct. 00:01:19.420 --> 00:01:21.560 So where did bcautomation come from? 00:01:22.040 --> 00:01:22.660 Let's go back. 00:01:24.140 --> 00:01:30.350 Most likely, bcautomation was identified as a username tied to test@example.com. 00:01:31.310 --> 00:01:34.560 The Username data type is likely the one that returned it. 00:01:35.040 --> 00:01:37.920 Let's look. Here's the culprit. 00:01:38.280 --> 00:01:42.920 Someone registered the bcautomation username on the gravatar site using the 00:01:42.920 --> 00:01:47.590 test@example.com email address. They probably wanted to avoid email from 00:01:47.590 --> 00:01:51.660 gravatar. In this case, this is a false positive. 00:01:52.040 --> 00:01:56.610 We can remove it from our results. Clicking the checkbox in 00:01:56.610 --> 00:01:59.260 the Data Element row allows us to select it. 00:02:00.740 --> 00:02:05.140 This button will let us mark the selected data as a false positive. When we 00:02:05.140 --> 00:02:09.560 mark a specific data element as a false positive, any data derived from that 00:02:09.560 --> 00:02:12.360 false positive is also marked as a false positive. 00:02:12.740 --> 00:02:18.480 Let's look. Notice now, each bcautomation result has a 00:02:18.480 --> 00:02:20.860 false positive icon attached to it. 00:02:21.340 --> 00:02:23.650 We can also remove those from our view. 00:02:24.540 --> 00:02:27.660 Here's where identifying false positives saves time. 00:02:28.040 --> 00:02:31.420 Marking false positives also marks any data elements that 00:02:31.420 --> 00:02:33.460 originated from that false positive. 00:02:33.840 --> 00:02:34.560 How cool is that? 00:02:35.540 --> 00:02:38.260 Let's turn our attention back to initiating scans. 00:02:38.740 --> 00:02:42.160 Seed targets are a starting point for information collection. 00:02:42.740 --> 00:02:46.660 Spiderfoot will take that initial target data and expand out from there. 00:02:47.140 --> 00:02:48.720 If we click into the box, 00:02:48.830 --> 00:02:51.700 we get some helpful information about the data types it 00:02:51.700 --> 00:02:53.950 will accept and how to format that data. 00:02:54.940 --> 00:02:59.460 There are two basic types, infrastructure focused, with domains, 00:02:59.470 --> 00:03:05.830 sub‑domains, hostnames, IP addresses, and ASN; or human focused, with email, 00:03:05.830 --> 00:03:08.660 phone number, usernames, and even human names. 00:03:09.640 --> 00:03:14.030 We'll need to be selective in the seed target that we use. Some, 00:03:14.040 --> 00:03:16.820 like human names, will return a lot of information, 00:03:17.070 --> 00:03:19.260 most of which will not be helpful. 00:03:20.040 --> 00:03:23.300 Others, like domains or subnet ranges, might be more 00:03:23.300 --> 00:03:25.050 useful depending on our needs. 00:03:26.540 --> 00:03:29.060 Once we enter our Seed Target, then we need to 00:03:29.060 --> 00:03:31.650 decide what and how much to gather. 00:03:33.140 --> 00:03:36.310 We can choose All, and Spiderfoot will take a very expansive search 00:03:36.310 --> 00:03:39.560 approach, potentially using every module available. 00:03:40.440 --> 00:03:43.460 Other options are more selective, in which modules are used. 00:03:43.940 --> 00:03:45.960 Footprint might use some port scanning, 00:03:46.090 --> 00:03:49.550 website spidering, and other active methods against the target. 00:03:49.940 --> 00:03:52.460 Investigate might be more useful when looking at 00:03:52.460 --> 00:03:54.460 entities that are assumed to be malicious. 00:03:54.940 --> 00:03:56.960 In addition to the footprinting approaches, 00:03:57.040 --> 00:03:59.490 modules will be used to look at block lists, 00:03:59.520 --> 00:04:04.920 deny lists, and other sources tracking malicious activities. Passive avoids 00:04:04.920 --> 00:04:08.060 those active methods in favor of indirect data collection. 00:04:08.440 --> 00:04:11.620 We also avoid interacting with the target systems that might 00:04:11.630 --> 00:04:13.560 indicate that we are collecting information. 00:04:14.540 --> 00:04:16.060 Here's a key fact to understand. 00:04:16.540 --> 00:04:20.160 Spiderfoot is selective in which modules are used in a scan. 00:04:20.540 --> 00:04:24.760 One piece of data gathered from one module will trigger other modules to run. 00:04:25.140 --> 00:04:25.890 For example, 00:04:25.900 --> 00:04:28.760 the domain name of example.com caused other 00:04:28.760 --> 00:04:32.040 domain‑oriented modules to run and gather data, 00:04:32.050 --> 00:04:35.460 which in turn caused other modules to run, and so on. 00:04:36.440 --> 00:04:39.780 If we want to be very granular in our scan configuration, 00:04:39.790 --> 00:04:43.780 we select the data types we need here, or we can select 00:04:43.780 --> 00:04:47.590 specific modules. We might use this if we want to include or 00:04:47.590 --> 00:04:49.960 avoid specific information sources. 00:04:51.440 --> 00:04:54.460 Let's take a look at a site intended to be scanned, 00:04:54.840 --> 00:04:56.550 and let's get footprint information. 00:04:58.040 --> 00:05:00.350 This can take a while, so I'll speed the scan up. 00:05:02.940 --> 00:05:07.020 We can see that the Status tab populates a simple graph showing the 00:05:07.020 --> 00:05:09.860 different data types gathered and the count for each. 00:05:10.340 --> 00:05:14.600 Since this was an active scan, we can see that the site was port scanned. 00:05:15.540 --> 00:05:20.250 There are three ports open, an NTP server on port 123, 00:05:20.740 --> 00:05:25.360 an SSH server on port 22, and a web server on port 80. 00:05:25.840 --> 00:05:28.660 We can also see where the site is hosted, and there's a 00:05:28.660 --> 00:05:31.970 lot more data here to explore. Up next, 00:05:32.150 --> 00:05:34.660 we'll look at the configuration of modules.