SOCIAL ENGINEERING AWARENESS PROGRAMS: PART 4
CLICKING THE PHISH: INTEGRATING WITH INCIDENT RESPONSE
The opinions expressed in this post do not necessarily reflect those of Joe’s employers: past, present, or future. While I am a security professional, I am not your security professional. The data included in this post is sound by current industry parameters, your mileage may vary.
It is inevitable that at some point, someone will fall victim to a social engineering attack. This could be via clicking the phish, letting an unauthorized person in, or succumbing to a phone scam. Integrating with your Incident Response plan (if you have one; otherwise read my next series) is vital.
Clicking the phish (falling victim)
There are some terribly bad phishing (or other social engineering) schemes circulating the world. There are some that are excellently crafted, grammatically correct, and timely. The conditions surrounding and timing of the attack can make or break it. Proper Open Source Intelligence (OSINT) gathering can enhance the odds of success.
Examples of successful phishing campaigns that I have either used or been aware of include:
- A blatantly bogus email with some links in it that look malicious. There is a conspicuously placed “Unsubscribe” Button at the bottom with the same link as above. This may be sent repeatedly as if the victim may have accidentally subscribed.
- Similar to the Unsubscribe campaign above, the Unsubscribe button is replaced with a “Report as Spam” button or link.
- An email sent to a Google/Gmail account that contains what appears to be an attachment download icon that redirects to a Fake Google Sign-on page.
Another vector to use is baiting. One could create an infected file as a PDF or other file format and implant it on a USB thumb drive. Multiple copies are made then “sprinkled” around the organization for people to find and plug in. The examples that I have provided are merely a few of nearly endless possibilities.
Instead of operating under an assumption that all attempts can be stopped is unreasonable unless the organization has no people or no information assets. Planning on when someone falls victim as opposed to if is the prudent thing to do. To compound on the previous post, a non-punitive model in terms of people falling victim reinforces positive culture and will allow better integration with Incident Response.
In the training, we talked about telling people the following:
- Successful Social Engineering
- Immediate Actions? Log off, step away, unplug network cable, or power the system down?
- Who should be notified? How?
- Provide specific email addresses, phone numbers, or office locations
- Phone calls? What to obtain and who/how to report it to?
- Remedial Training?
Focusing on the Successful Social Engineering, the proverbial devil you know is better than the devil you don’t (most of the time). The reason that immediate actions need to be reported is to give the IR team a head start on context as well as where to look in terms of IP Addresses, applications, and actions. This will tremendously expedite the Identification, Eradication, and Containment phases of IR. Taking the time to spell out the contact chain and methods of contact to remove the guess work removes any possibility of the wrong party being notified.
In conclusion, building in the social engineering response into the IR process will better protect your organization in terms of resiliency. As the cliche goes, failing to plan is planning to fail. While these solutions do not provide an absolute solution, nothing ever will.