In this demonstration,
we'll take a look at reviewing scan results and
initiating different types of searches.
In our previous demo, we kicked off a simple scan.
We will look at those results and the scan report interface.
Spiderfoot has a method for marking false positives, which we'll examine.
We'll also look at the options for different scans,
starting with the idea of seed targets,
the use cases we might utilize, and the various data
types that Spiderfoot processes.
Let's take a look at our previous scan.
Our First Scan was a contrived scan looking at the
test@example.com email address.
Be aware that example.com was created by the Internet
Assigned Numbers Authority for uses like this.
There shouldn't be anyone using test@example.com.
However, we can see that there are some results from that scan.
To examine those results, click on the scan name. Here the
scan results are grouped by data type.
Let's look at the first data type, Account on External Site.
Here we can see that the sfp_accounts module has identified a
couple of accounts for bcautomation.
I bet you're thinking, wait,
weren't we looking for test@example.com? That's correct.
So where did bcautomation come from?
Let's go back.
Most likely, bcautomation was identified as a username tied to test@example.com.
The Username data type is likely the one that returned it.
Let's look. Here's the culprit.
Someone registered the bcautomation username on the gravatar site using the
test@example.com email address. They probably wanted to avoid email from
gravatar. In this case, this is a false positive.
We can remove it from our results. Clicking the checkbox in
the Data Element row allows us to select it.
This button will let us mark the selected data as a false positive. When we
mark a specific data element as a false positive, any data derived from that
false positive is also marked as a false positive.
Let's look. Notice now, each bcautomation result has a
false positive icon attached to it.
We can also remove those from our view.
Here's where identifying false positives saves time.
Marking false positives also marks any data elements that
originated from that false positive.
How cool is that?
Let's turn our attention back to initiating scans.
Seed targets are a starting point for information collection.
Spiderfoot will take that initial target data and expand out from there.
If we click into the box,
we get some helpful information about the data types it
will accept and how to format that data.
There are two basic types, infrastructure focused, with domains,
sub‑domains, hostnames, IP addresses, and ASN; or human focused, with email,
phone number, usernames, and even human names.
We'll need to be selective in the seed target that we use. Some,
like human names, will return a lot of information,
most of which will not be helpful.
Others, like domains or subnet ranges, might be more
useful depending on our needs.
Once we enter our Seed Target, then we need to
decide what and how much to gather.
We can choose All, and Spiderfoot will take a very expansive search
approach, potentially using every module available.
Other options are more selective, in which modules are used.
Footprint might use some port scanning,
website spidering, and other active methods against the target.
Investigate might be more useful when looking at
entities that are assumed to be malicious.
In addition to the footprinting approaches,
modules will be used to look at block lists,
deny lists, and other sources tracking malicious activities. Passive avoids
those active methods in favor of indirect data collection.
We also avoid interacting with the target systems that might
indicate that we are collecting information.
Here's a key fact to understand.
Spiderfoot is selective in which modules are used in a scan.
One piece of data gathered from one module will trigger other modules to run.
For example,
the domain name of example.com caused other
domain‑oriented modules to run and gather data,
which in turn caused other modules to run, and so on.
If we want to be very granular in our scan configuration,
we select the data types we need here, or we can select
specific modules. We might use this if we want to include or
avoid specific information sources.
Let's take a look at a site intended to be scanned,
and let's get footprint information.
This can take a while, so I'll speed the scan up.
We can see that the Status tab populates a simple graph showing the
different data types gathered and the count for each.
Since this was an active scan, we can see that the site was port scanned.
There are three ports open, an NTP server on port 123,
an SSH server on port 22, and a web server on port 80.
We can also see where the site is hosted, and there's a
lot more data here to explore. Up next,
we'll look at the configuration of modules.