174. Reasons for Communication (OBJ 4.3)
In this lesson, we’re going to discuss the different reasons for communication during a penetration test or engagement. These reasons include situational awareness, de-confliction, de-escalation, identifying false positives, criminal activity, and goal reprioritization. The first reason that a penetration tester needs to communicate with the target organization, is to ensure that both sides have situational awareness during the engagement. Situational awareness is a perception of the different environment elements and events with respect to time or space, the comprehension of their meaning, and the projection of their future status. Now, this is really a complicated way of saying that situational awareness, is focused on your ability to know what is going on around you during the engagement, and it’s also important that this happens on both the penetration testers side and the organization that is the target of that engagement. By having a good communication between the testers and the organization’s points of contact, we’re going to be able to create a shared understanding of the network and its current security state.
For example, if we’re attacking a Windows domain environment, then we’d probably have to have some kind of communication between the penetration testing team, and the trusted network defenders. Otherwise, those defenders may think there’s an actual attacker on their network. We also need situational awareness inside the penetration testing team itself, because our team could consist of 5 to 10 different team members, if we’re going after a large target, and so we need to make sure that each team member, knows roughly what the other team members are doing. Some teams divide up the responsibility for certain parts of the engagement, such as having one or two people focused on performing the reconnaissance, and then passing along anything they find to another team member, who’s going to conduct the enumeration. That person will then pass on their results to team members who are responsible for the actual attack and exploitation, and they will, in turn, pass that target over to a post-exploitation team member, who’s going to conduct the privilege escalation, lateral movement, and establishment of covert channels. All of these team members need to communicate and share information, in order to create a shared situational awareness amongst the team, so they all have a better understanding of the network and the team’s overall plan of attack.
The second reason that a penetration tester needs to communicate with the target organization, is to conduct de-confliction. De-confliction is a communication process, that occurs between the penetration testers, the organization’s points of contacts, and the organization’s own cybersecurity defenders. De-confliction is going to be used to determine if a detected activity, is a real attacker acting against the target network, or if it’s an authorized penetration tester doing it. If it’s been determined that the activity was conducted by the penetration tester, then the defenders are going to take actions to block or remove that penetration tester, as part of their normal cyber security activities. But, if the suspected attack didn’t come from the penetration tester, the target organization, is instead going to tell the penetration testers to stop all activity, while they investigate and respond to the real-world attack that they just discovered.
To help with the de-confliction, the penetration testing team should have a trusted agent, who is working for the target organization, and who is conducting their daily work in the security operation center, or the system administration team. That way, when they hear that one of their coworkers found something suspicious, they can reach out directly to the penetration testing team, to de-conflict that activity as either a malicious actor or an authorized penetration tester. Essentially, this rusted agent knows that the penetration test is happening, and they may even know what systems are being targeted. This person, is going to be given a direct line of communication to the penetration testers, so that if they see something come through their network logs, they can call that testing team up, and ask them, “Was it them or not?” The third reason that a penetration tester needs to communicate with the target organization, is to conduct de-escalation. De-escalation is the process of decreasing the severity, the intensity, or the magnitude, of a reported security incident.
Now de-escalation often goes hand in hand with de-confliction. For example, after an alert has been de-conflicted as being performed by the penetration testers, that trusted agent, may reclassify an alert to a lower level, such as from critical to medium, inside of their incident response system. Similarly, the de-escalation could work in the other direction too. For example, let’s assume that the organization is seeing what they think is a denial of service attack going against their servers. The trusted agent could contact the penetration testers, and they might verify that it’s actually them causing the denial of service because they’re conducting a stress test. That trusted agent now knows the source of the activity, which means it’s been de-conflicted. But, they may also ask the penetration testers to dial it back some, to decrease the severity of that stress test.
For example, maybe the penetration testers are hitting the organization with an excess of one gigabits per second of bandwidth utilization during that stress test. And the organization now wants to request that they scale it down, to only 10 megabits per second, to prevent running up a large cloud services bill, due to all that unnecessary traffic. The fourth reason that a penetration tester might need to communicate with the target organization, is when the identification of false positives occurs. Now, when you’re conducting an unknown environment test against a target organization, there’s going to be things that you simply don’t know about a given network. So, when you conduct your vulnerability scans against the target network, and you receive a long list of vulnerabilities back from your tool, you’re going to need to be able to identify if those are true vulnerabilities or false positives.
As a penetration tester, you don’t want to waste a lot of your time with false positives. So you may use a results validation process with a trusted agent in the target organization, to help you identify what findings may be false positives. For example, if I ran a vulnerability scan against an organization’s forward-facing web servers, and it came back with 103 vulnerabilities, I might work with the trusted agent, to see if they have a web app application firewall in place that could be mitigating some of those vulnerabilities, even though the scanner doesn’t recognize that that firewall has already been implemented. Similarly, it might find a vulnerability associated with a particular version of a database that’s connected to the web server, even though that version of the database server isn’t being used on the network because of a misreading by that vulnerability scanning tool. By working with the trusted agent to validate your scan results, if your scope of work allows you to do this, you’re going to be able to help minimize the amount of time that your penetration testing team has to spend trying to exploit vulnerabilities that are really just false positive. The fifth reason that a penetration tester needs to communicate with the target organization, is when the discovery of criminal activity occurs.
Now, this criminal activity goes beyond just finding evidence of an indicator of prior compromise though. It may involve ongoing criminal activity within the target organization itself, or by one of its employees. For example, during one penetration test I was working on about 10 years ago, we discovered some photographs on an employee’s computer, that contain what appeared to be pornography with underage models. When we saw this, we immediately stopped the engagement, contacted our local law enforcement agency, and brought them in to take over the collection and identification of those images. In this case, it wasn’t the organization that broke the law, but instead, it was an individual employee who used their work computer to download legal photographs. Conversely, you may find some kind of illegal activity that’s conducted by the organization itself. For example, if the organization is a publicly-traded company, you might find evidence that they’re trying to manipulate their stock price for their own benefit, and this could be an illegal activity.
Again, in these cases you need to consult your lawyer or your legal counsel, to determine the appropriate next steps if you uncover criminal conduct, that’s occurring at your engagement’s target organization. The sixth reason that the penetration tester needs to communicate with the target organization, is to conduct goal re-prioritization. Now, back in our planning and scoping phase, we work closely with our clients, to be able to solidify our scope of work and the resulting contract, based upon the planned and agreed-upon goals for the assessment. Unfortunately though, sometimes these things change and the goals need to be reprioritized or change completely. For example, we might be going into a network to conduct a PCI DSS scan against their organizational network, and then we are scheduled to do a full penetration test. But while we started scanning the network, we discovered that the organization’s patch management and vulnerability management systems, are simply horrendous. At this point, doing a penetration test would be pretty useless to the organization because they have so many vulnerabilities across all their systems, due to their improper patch management. So we might need to reprioritize the goals for this engagement, to remove the penetration test and instead, change this into a consulting engagement, to show their team how to configure and use proper automation, in order to conduct better patch management.
If we instead continue to do the penetration test, we would really just be wasting time and resources because that money would’ve been better spent fixing the real issues they’re facing. It’s also important to realize that penetration tests are always a fluid thing, and priorities do change during the engagement. For example, you might be allowed to conduct social engineering and phishing campaigns at the beginning of an engagement, but then the client sees you’re having too much success, because their employees aren’t properly trained, in how not to open suspicious emails. In this case, the client may want to reprioritize the goal from initial access, by any technical or non-technical means, to simply finding initial access vectors by technical means, that do not involve social engineering. In other words, they want you to find technical vulnerabilities, and stop exploiting the social engineering component because you’ve already been successful using that exploit method.
Or you may have gotten into the network and started attacking their customer-facing web server. But now, they want you to reprioritize your attacks against their database server instead, because they already have a contract in place to rebuild the customer-facing web server, and it’s going to be fully replaced in the next four weeks, So going against it now and finding all of its vulnerabilities, is really a waste of your time. This may not have been planned six months ago, when you did the initial goals that you created during the planning and scoping phase But now, this becomes a matter of goal re-prioritization because we have this change in status from six months ago, to what’s happening in the next four weeks. As you can see, there are a lot of different reasons to communicate with your clients during a penetration test or engagement. These reasons include things like situational awareness, de-confliction, de-escalation, identifying false positives, criminal activity, and goal re-prioritization. So keep that in mind when you’re doing you engagements.
175. Presentation of Findings (OBJ 4.1 & OBJ 4.3)
In this lesson, we’re going to discuss the presentation of findings when you complete your engagement. Now, the first thing to keep in mind when you do your presentation of your findings is to understand who is your audience. Depending on your audience, you are going to present your findings in different ways. For example, is your audience the C-suite, a third-party stakeholder, the technical staff, or the developers? Each of these is going to be looking for a different result as you present your findings to them. If you’re briefing the C-suite, this refers to the top level management inside of an organization. They’re called the C-suite because all their names start with the word, chief. For example, the chief executive officer, the chief financial officer, the chief technical officer, the chief information officer, the chief security officer, the chief information security officer, and people like that. Now these people are senior executives and they are likely going to be responsible for making large decisions in the organization. Generally, these decisions are going to be based on budgetary needs and resources that’ll be assigned to a program.
So if you come to them and start talking about SQL injections and how you use a particular exploit to get into a certain system, their eyes may glaze over when they’re listening to you. Instead, what they want is the big picture. How vulnerable is their organization? What can they do to stop those vulnerabilities? How much money is it going to take? How many people is it going to take? How much time is it going to take? That is the level of detail that the senior management is really looking for. So as you start bringing up your findings to senior management, you need to be prepared to put a cost number associated with it. For example, if you found there was a lot of vulnerabilities associated with particular server, that there could have been injection attacks against them and you want to put a web application firewall in front of it, you need to tell them that the installation is going to cost X dollars and it’s going to cost you one full-time equivalent person to run it per year. And that’s going to cost Y dollars to be able to operate this over the next five years.
Now, at the same time, as you’re presenting all these costs, you also need to present them with the benefit. If I’m going to spend $200,000 to buy a web application firewall and another $100,000 per year for the salary of somebody to run it, what is the benefit I’m getting? Well, it’s going to prevent you from having X data breach that may cost you Y amount of money. And so, by being able to give these comparisons, it’s going to help the C-suite take your information and your findings with actionable recommendations that they can then implement. The idea here is when you’re dealing with upper management, they are looking at the big picture. So you need to be speaking their language when you’re providing them with your findings and recommendations. Now, the second category we have is third-party stakeholders. Now third-party stakeholders are people that are not directly involved with that particular organization or client, but they’re still involved in the process related to the different penetration tests that you’ve done. For example, if you did a PCI DSS compliance check against an organization, the third-party stakeholder is going to be the bank or merchant processor that’s asking for a copy of those results because they’re the ones who are backing up the credit card processing for that organization. The objective here when you’re dealing with third-party stakeholders is to ensure that you’re meeting the regulatory compliance. So again, they’re not necessarily looking at every single finding individually, but they’re looking more for almost like a report card.
Is this an A organization, a B, a C, a D, or an F? And based on that, they can then know if that organization has a good cybersecurity posture or not and if they’re meeting their regulatory compliance requirements. In addition to that, if you’re dealing with a regulatory compliance requirements, there’s often a specific format that your reports will need to be written in, that meet those requirements. For example, for PCI DSS, there are templates available for you to be able to put your report into those templates. The third audience you may come across is the technical staff. Now the technical staff are going to be looking for a detailed report because they want to be able to fix their networks based on your findings. So these folks are actually going to care about the exact commands you issued, the exact servers you were in, what the IP addresses are, what the different remnants that you left on those servers to prove you were able to attack it. All of that stuff are the details that the technical staff want to know. They will understand when you say that the MySQL server is running version 6.1.2 and it should be running version 6.3.4., for example.
Now, if you did that to the C-level suite, they would not understand what you’re talking about, nor would they care. But you technical staff really do care about these finer details. For them, they want to know the ways you are able to exploit them and how you’re able to break into the network, as well as what you recommend they do to prevent people like you or real world attackers from breaking into their network again. The fourth audience we deal with are developers. Now developers are even more technical than your technical staff. The technical staff are the ones who are going to be operating the networks and being able to put large operational pieces in motion to be able to patch, scan, and protect their networks. But the developers can actually change code.
So if you were dealing with the developers for particular web application, these developers want the really deep technical detail for how they can make their programs better and be able to stop future attacks from occurring. So when you’re working with the developers and providing reports for them, you’re going to be going down into very deep technical details. This may include even code examples or the different types of data sets that you injected into their system to create the faults. This helps the developers be able to fix their systems and ensure that those vulnerability can be removed forever. So when you’re doing your presentation of findings, keep this in mind. If you’re dealing with the C-suite executives and senior management, you want to keep things at a broad high level that is focused on the business and the cost to them.
If you’re dealing with the third-party stakeholders, you want to meet what their requirements are as well, which are normally going to be focused on regulatory compliance and ensuring the organization has a proper cybersecurity baseline. If you’re dealing with the technical staff, they’re going to be looking for details and ways that they can change things using different operations, software, or security patches. And when you’re dealing with developers, they’re looking for deeply technical information so they can change the code that runs those applications and prevent vulnerabilities from happening in the first place.
