Hello and welcome to another penetration testing execution Standard discussion. Today we're going to talk about passive testing within the vulnerability analysis phase of the Pee test standard. So quick disclaimer the tools and techniques that we use and discuss our use for system hacking.
And so any tools or techniques that we use or discuss
should be understood and researched by the user. Please research your laws and regulations for your given area regarding the use of such tools to ensure that you do not get into any trouble with the law. Now let's jump into our objectives for today's passive analysis discussion. This is a very brief discussion.
We're going to look at what passive vulnerability analysis is.
We're going to look a vulnerability analysis within metadata, and we're going to look at traffic monitoring. So
what is passive analysis? Well, passive announces is the active monitoring a network's traffic in an attempt to classify a notes operating system, ports and service is and to discover vulnerabilities that an active scanner like open boss next pose may not detect. So that is the goal.
Now metadata analysis with impassive analysis is when we look at data that describes files as opposed to the file data itself.
A Microsoft office document, for example, might list the author company when the document was last saved, when the document was created and so on. So many documents have even entries of custom metadata, and this could potentially contain internal addresses of Scene I P addresses.
I've seen email addresses paths to servers,
um, and other informations that that a tester could use potentially to gain an edge in their penetration testing efforts.
Now, traffic monitoring
is the concept of connecting to on an internal network in capturing data for offline analysis. Now, route poisoning is excluded from this phase as these create noise
and the goal here is to not be detected is often surprising how much data you can actually get from a switch network. This leaking of data on a switch network can be categorized as follows.
So we've got our friend Matt cash overflow, causing switch packets to be broadcast. This is common on Cisco switches that have been proper Arpin Matt cash timing configurations, ether leak, some older network drives and some embedded drives will use data from system memory to pad our packets.
If enough our packets can be collected. Sensitive information from internal memory can be captured
miss configuration of clusters or load balancers
hubs plugged into the network. Note that some of these categories only result in data leakage to a single sub net,
while others can result in leakage to a much larger network segment. So with a switch network, you won't pick up a CZ much traffic as faras What you're monitoring on a hub because everything is sent out to everybody for review,
you would likely pick up more data. And so again, passive analysis is really kind of going above and beyond with respect to testing, It's going to take a lot of additional time on a switch network unless you're, you know, nearing the switch traffic out of a single port for analysis or you get permission to do so.
But really again, Depending on the goal of the test, you may do some pack. It captures with something like wire shark, um,
to see if maybe traffic is not encrypted. Deceive you can capture password information over the network really again depends on scope and the rules of engagement with respect to the current test.
Now let's do a quick check on learning True or false passive analysis involves the use of tools to scan systems and identify service is running on those systems.
All right, well, if you need more time, please go ahead and pause the video. Remember that passive analysis does not involve scanning of systems were simply going to monitor traffic, pick up data, listen to what's going on. An attempt to identify service is running on those systems or what those systems are. So this is a false
statement. We do not scan systems when we're doing passive analysis.
we discussed what passive analysis is we reiterated metadata and some analysis of it and what it can do for us and traffic monitoring again. All of this is dependent upon the client need
and the goals of the overall testing of those systems and what you're trying to achieve. So with that in mind, I want to thank you for your time today, and I look forward to seeing you again soon.