How to handle social engineering penetration testing results

Responding to Phishing

Now that you understand the basics of incident response, you need to define what users should do if they fall victim to the various kinds of social engineering attacks. Let's start with phishing. A phishing email that contains links or files might allow an attacker to gain access to your systems. Your goal, then, should be to expedite containment and eradication.

One tip for making rapid responses possible is to choose a single nonblack color for all networking cables. This will allow you to instruct employees to unplug that colored cable from the back of the computer or the wall. Bear in mind that systems may still be connected to the network wirelessly, and you should define behavior for disconnecting wireless devices as well.

Ask users to report the approximate time at which the incident occurred. This detail helps the security team locate the logs they should comb through, rather than leaving them with no clues as to where to look. Upon falling victim to the attack, users should either log out, lock their screen, power off, unplug from the network, or hibernate their system. The actions that a user should take depend on the organization's capabilities and its potential response to a given incident. For example, if no forensic analysis will occur, there is no reason to hibernate the system. Alternatively, if the organization is going to rebuild the system from known, good media, the correct action may be to just shut down the system after gathering the artifacts.

The user should also report the source email address or website of the phish, any windows and applications that were open, and whether anything unusual happened on the screen.

You should print out these guidelines, laminate them, and put them in each user's physical workspace. At any given time, a user should be able to reference the sheet and perform the required actions.

Responding to Vishing

While similar to phishing, vishing presents unique challenges. In the absence of monitoring all phone calls, the ability to identify and act upon vishing calls relies upon the staff reporting them, as well as knowing the actions to take in advance. No widespread or accurate intrusion detection systems (IDSs) or SEIMs encompass phone calls. Companies can monitor the internet traffic of any phones connected to the corporate Wi-Fi network, but not ordinary phone calls or their context. Fortunately, an attacker cannot (immediately) log in and take over a network from a phone call. Even if someone who is vishing gets information, technical controls might prevent them from causing further harm. Regardless, you must define actions for responding to vishing attempts.

First, upon noticing that they are experiencing a vishing attack, users should either hang up, ask to call back, try to get information out of the caller, or lie to confuse the caller. Security management within the organization will need decide which actions to train employees to perform. A level of risk is associated with encouraging users to solicit information or lie; the user may give up valuable and accurate information inadvertently. Users should then contact information security and provide the approximate time at which the incident occurred, any actions they took, the phone number that called them, the information they were asked, and the information they provided. They should also provide any additional information about the caller, such as their accent, dialect, tone, or mood, or the presence of background noises.

Responding to OSINT Collection

Detecting OSINT collection is hard, because platforms like Shodan, Censys, and Have I Been Pwned don't automatically allow you to set alerts on queries, though you could write your own code to set alerts for whenever the organization's assets appear on such platforms. Have I Been Pwned allows organizations that can demonstrate ownership of a domain to set up such alerts, but will not share any breached credentials belonging to accounts on the domain. But since OSINT collection typically takes place in the reconnaissance phase of an ethical hacking engagement, it's common to see it occur alongside scanning and enumeration, which are detectable.

The first layer of detection lies within a CDN like Cloudflare or Amazon CloudFront, if used. The next layer is within the web server logs or the application logs of the web applications. These sources will educate the organization as to who is scanning and what is being scanned. Often this will lack the context needed to differentiate between web scanning en masse and an actual adversary attempting to collect OSINT or working through scanning and enumeration.

Decide what actions you should block. Examples can include blocking users after a certain number of 404 errors caused by spidering; blocking or rate-limiting spidering to a certain number of events per second; blocking anyone who downloads a certain number of public files, using a specific user-agent string in the browser or script; and blocking users who navigate to a honey page.

Handling Media Attention

Depending on the severity of the attack, the publicity it receives, and other events happening in the news cycle, the media may seek to speak with people from your organization during an incident. While doing so should not be your top priority, failing to respond to media inquiries can send a worse message than if you just admit that you don't know all of the details at this time. While the media should reach out to the organization's public relations team, some may attempt to contact and interview any employee.

To control the message being conveyed to the public, enforce a media blackout on all employees except those defined in your incident response plan. Provide unauthorized employees with a template response for handling such inquiries. This can be as simple a statement as "I am not authorized to discuss the details of the subject of your request" or a redirect to the designated media representative at the company.

The parties who are authorized to talk to the media must understand what tone to take, how to decline to answer, and whom to speak with in order to learn the facts they will share with journalists. Also define a person or committee to review and approve any messages that the public relations person will provide the media.

I also highly recommend consulting with your organization's internal PR team and any external PR consultants that your organization uses. They will be able to speak to your organization's specific policies and procedures, whereas I am speaking in more general terms.

How Users Should Report Incidents

If you don't tell users how they should report suspected incidents, they may bombard a gate guard who has no means of resolving the problem. One strategy is setting up a [email protected] email address to collect the phishing emails that users receive. You might also set up [email protected] or [email protected] as catchall addresses that forward emails to the appropriate parties.

When a user has fallen victim to a phish and may have introduced malware to the environment, reporting via email may not be the best approach. That's because it's possible that the entire email system has been compromised and that attackers can read, block, or alter the message. Depending on the size of the organization and whether a user is onsite or remote, you could direct users to report the incident face-to-face, call a phone number, or send a message using private chat or a secure texting platform like Signal, Wickr, or Wire.

Technical Controls and Containment

When it identifies a phishing email, the security team should collect the email, and any relevant information about it, while adhering to organizational policies and procedures. This will pay dividends when producing threat intelligence, which may be necessary depending on which industry the organization is in and whether it belongs to any Information Sharing and Analysis Centers (ISACs).

From the email itself, you should collect the source email address, details about whether the email address was spoofed (which is discussed in Chapter 12), and the source IP address. You should also block the source addresses and check logs to see if any other users or hosts communicated with the source addresses. To analyze the attack further, use the tools discussed in Chapter 12.

If the phishing scheme involves a malicious file, you can upload it to the malware-detecting website VirusTotal to get a quick answer about the file's content, assuming it is known malware. Additionally, take a cryptographic hash of the file, and check systems on the network for files that produce the same hash. Tune the SEIM to alert you about incoming instances of this file as well.

Sinkhole any IP addresses or URLs associated with the phishing email to redirect users to a benign page and set up alerts on workstations for those who attempt to access the malicious site. Once the email is sinkholed, the security team can contact all users, advising them to avoid the email. Once the incident is in the recovery phase, transition the information collected to threat intelligence and follow the organization's guidance on publication and distribution.

Excerpted from Practical Social Engineering by Joe Gray. Copyright © 2021 by Joe Gray. Excerpted by permission of No Starch Press. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.