In this article, we will dive deep into the sea of phishing and vishing, sharing real-world stories and insights we’ve encountered during social engineering tests to highlight the importance of awareness. Read on as we uncover real tactics and discuss effective strategies to protect your company and its sensitive information in today’s digital landscape.

Email Phishing Using an Open SMTP Relay by Michael Jereza, Senior Security Consultant 

A customer engaged with us to perform phishing assessments on its subsidiary companies without providing any information on targets or email configurations.  

Initial Access Attempt 

After collecting a list of just under 1,000 potential emails and getting customer approval, our team attempted an initial phishing campaign. However, no emails were opened during this initial campaign. We suspected there was some sort of email filtering blocking external senders in place, which was the case for previous assessments of the customer’s other subsidiaries. 

Part of the requirements for a standard phishing test is allowlisting our sending domains. However, since this parent company does not manage the email filters for each subsidiary we could not proceed with the assessment. Even in the most perfect scenario, a phishing campaign will inevitably get blocked when you’re sending emails to 1,000 people. 

Exploitation 

Then, around midnight, one of the security experts performing the external penetration test on this subsidiary shared that he had found an open SMTP relay. 

After getting customer approval, we re-sent the email campaign through this relay. It made our phishing emails appear to come from the legitimate “@company.com” domain rather than our registered phishing domain @comprany.com.  

The following email was sent:

Each hyperlink was actually embedding the phishing domain “company.com”, but it appeared as the legitimate domain for anyone who didn’t hover over the links.  

Results 

• Several email links were clicked out of all emails sent
• People entered their credentials on a fake Microsoft SSO page, some did this multiple times 
• According to LinkedIn, the credentials belonged to many leadership positions

This ultimately resulted in a SOC incident for the subsidiary and the most successful email campaign we’ve performed for this customer. The scariest part is this unauthenticated email relay was easily accessible from the internet, and anyone could’ve successfully phished this company.

Social Engineering Prevention Tip

While the company was implementing strong email protections, a fairly simple vulnerability allowed us to bypass these controls. This highlights the importance of defense-in-depth, as one flaw rendered the security mechanisms ineffective and allowed us to further pivot into the organization. 

In-Depth Vishing Attempt by Dalin McClellan, Principal Security Consultant

To more accurately simulate a real-world attacker, a customer wanted to provide us with as little information as possible for a phone-based social engineering engagement. I was given the name of the company and a goal of targeting 30 employees using phone-based social engineering to gain as much access as possible, especially access to executive-level accounts. The customer didn’t provide any other information. 

Recon

Initial Open-Source Intelligence (OSINT) research turned up names and emails of about 2,000 individual employees across 10+ countries and five domains. A few clever Google dork searches also helped me discover their internal employee portal. The portal helpfully included an unauthenticated and non-rate-limited API which allowed me to quickly verify which email addresses I had were valid, and also told me which business branch the employee works in. 

I narrowed down my list of targets to 30 valid employees, ranging everywhere from low level admin assistants to C-suite executives. 

Next, I began exploring their phone system. I found that if you called their main corporate phone line after hours, they had a dial-by-name directory which disclosed the direct-dial phone number of the person whose name you entered. Two hours of manual, late-night calls later, and I had phone numbers for all of my targets. 

Initial Access

I began making phone calls to employees, telling them I was from their internal IT department, and doing some follow-up on old support tickets that never got closed. “Everything good on your end? No more issues getting on the VPN? Great, can I have you check one thing for me? Go to [example].com and enter your credentials.” 

Using that method, I got three people to enter their credentials on a custom phishing site right away. Unfortunately for me, they had MFA enabled on all of their accounts. I still couldn’t log in without that code!

Not one to easily get discouraged, I made another call. This time, as soon as the person entered their credentials in the phishing site, with them still on the phone, I quickly went to the legitimate employee portal and attempted to sign in as them. After entering their username and password, I asked if they had received an MFA code. They said they did, and (without even being asked) happily read it out to me over the phone. I entered the MFA code on my computer and was now signed in to their account.

Exploitation 

I now had internal access to their employee portal! I wanted to make sure I was able to get back into the account if I ever got signed out, so I added my own phone number as a secondary MFA provider. That way I could re-login to the account whenever I wanted and could receive the MFA code to my phone. Also, just for backup, (and to prove it wasn’t a fluke) I repeated the process a few more times, until I had full access to three different employee accounts, including an internal software developer.  

Time to start digging around! I quickly found that the employee portal linked to Citrix, giving me access to internal desktops with local admin permissions. For this engagement, a full internal penetration test/red-team style escalation was out of scope, but almost certainly possible. 

Continuing, I dug through documentation on their internal SharePoint and found an account with weak credentials and no MFA enabled. The account was intended to only be used internally for password resets and troubleshooting. However, Patrick Sayler discovered that this “internal only” account was able to sign-in externally, and could access their internal SharePoint site as well as Azure AD. This meant we had nearly unauthenticated access to all their internal documentation, as well as their entire internal employee directory. 

I sent a message to the customer letting them know about this gap. They shut that account down right away and gave us big kudos for finding it and bringing it to their attention, even though it wasn’t technically part of the test. 

Executive Escalation 

We took this test further and targeted executives. I registered a new domain similar to their legitimate employee login domain, then spun up an Evilginx server which proxied traffic to their legitimate employee login site and captured credentials entered, including MFA codes as well as session tokens.  

Next, I used one of my previously compromised accounts to access Microsoft Teams. With everything ready, I placed a call to one of their corporate executives. Claiming to be a software developer, I said that I was working on a new “exclusive to executives” authorization flow, but I need someone with that level of account to sign-in to it so we can “generate some logs we need on the back end.” 

At first, the executive was skeptical, but I used the compromised account to send a confirmation message through Microsoft Teams, along with a link to the phishing website. A few moments later, the executive entered their credentials into the phishing site, which were immediately captured and replayed, giving me access to the account.

Social Engineering Prevention Tip

Emphasize and re-emphasize that employees should NEVER, EVER, under ANY circumstances give an MFA code to ANYONE, even other employees. Make sure employees understand that those tokens are essentially a second password for their account and should be treated as securely as their primary password.  

Audit account access and permissions regularly, especially any non-standard accounts with unusual purposes. Test your security controls to make sure things that should only ever be internal are, in fact, internal only.  

Tips from The NetSPI Agents 

For security teams and leaders, it’s important to remember that social engineering is still the top method threat actors use to enter a company’s IT and security environment. Here are a few tips to ensure that your company and the people in it are resilient to these types of attacks. 

• Implement Strong Technical Controls: Establish robust security measures to mitigate. the impact of successful phishing attacks, including MFA to add an extra layer of security. 
• Streamline Reporting Processes: Create an easy, user-friendly system for employees to report suspicious activity and phishing attempts, minimizing reliance on traditional help desk procedures. 
• Run regular social engineering penetration tests. 

For more tips and a deeper dive into social engineering, check out our blog post: Ask These 10 Questions to Enhance Your Social Engineering Testing. 

The post Social Engineering Stories: One Phish, Two Vish, and Tips for Stronger Defenses appeared first on NetSPI.

Don’t wait for a breach to happen before you pursue social engineering testing. Be proactive and enhance your internal processes to increase your defenses against an attack. Get the most value out of your social engineering testing by asking the questions below to maximize results.

Get the full list of questions below. 

Introduction 

Your multifactor authentication (MFA) is tailored to your environment; you’ve got regular software updates down to a science; and your company’s social engineering training has boosted your team’s recognition of phishing attempts.

These efforts build up to a proactive security strategy that’s needed to combat today’s persistent social engineering attacks. But all this aside, one fact remains — social engineering is still the top method threat actors use to gain entry to a company’s IT environment and sensitive data. 

Social engineering is still the top method threat actors use to gain entry to a company’s IT environment and sensitive data.

For security teams and their leaders, understanding how to effectively conduct social engineering penetration testing can be a game-changer. Not only does it help identify focus areas to enhance security, but it also builds a robust defense mechanism against the real threats that exist today. 

Learn why social engineering remains a prevalent threat, the difference between phishing/vishing and physical/on-site penetration testing, and how you can maximize the outcomes of your social engineering testing by asking specific questions. 

Whether you’re just learning more about social engineering testing, or you’re ready to start your next engagement, NetSPI is here to help. Let’s talk.

Social Engineering Attacks Are All Too Common

Social engineering leverages human psychology to exploit individuals to share sensitive information or perform actions that compromise security. Unlike traditional techniques threat actors use that target systems and networks, social engineering attacks target the weakest link in the security chain — people.  

By prioritizing social engineering penetration testing, organizations can build a human firewall that is just as strong as their technical defenses.

This focus not only protects against breaches, but it also fosters a culture of security awareness among employees. 

73% of Breaches Are Due to Phishing and Pretexting

Social engineering remains a prevalent threat. Pick up any cybersecurity report or peruse data breach headlines, and you’ll quickly get a sense of the threat landscape.  

The Verizon Data Breach Investigations Report highlights that phishing remains the leading cause of incidents, accounting for 73% of breaches. This statistic has remained steady year over year, underscoring the persistent nature of social engineering threats. 

Another telling insight from the report is that “the median time for users to fall for phishing emails is less than 60 seconds.” This rapid response time emphasizes the importance of real-time awareness and training to recognize, report, and ultimately prevent social engineering attacks. 

Prioritize Social Engineering Defense 

Several indicators can signal the need to prioritize social engineering prevention within an organization.  

Phishing and Vishing 

On the phishing and vishing side, headlines like the high-profile MGM data breach spike interest in social engineering prevention. When a competitor or someone in your industry falls victim to a social engineering breach, it serves as a compelling signal to initiate social engineering testing. 

As technical controls grow stronger and the industry expands, it’s challenging to prevent social engineering tactics like phone calls. For example, while web application firewalls and network controls can block foreign threat actors, even a teenager in Florida can try to infiltrate through simple phone calls. 

Physical Pentesting 

On the physical security side, the COVID-19 pandemic significantly altered on-site security. With more people working from home, buildings are less populated, making it easier for unauthorized individuals to gain access because of outdated assumptions about physical security based on pre-pandemic conditions. 

If you’re considering whether you should put more weight into social engineering prevention, the answer is probably yes.

The best advice we can give to avoid a data breach is to be proactive and prepare ahead of time. 

Social Engineering Penetration Testing versus Social Engineering Prevention Training 

Training and testing serve different purposes, but are both essential for a comprehensive security strategy. 

Social Engineering Prevention Training 

Popular subscription-based social engineering training services focus on educating employees to recognize and report phishing attempts. These sessions are broad in nature, accessible to all employees, and can be mandated organization-wide. 

Social Engineering Penetration Testing 

With social engineering penetration testing, security teams take a more sophisticated approach, resulting in deeper insights by seeing what could happen after phishing occurs. This type of testing evaluates how employees respond, identifies potential escalation points, and provides helpful context into the organization’s resilience against social engineering attacks. 

While training casts a wide net for general recognition and reporting, penetration testing evaluates specific attack paths for precise security enhancements.  

Questions to Ask to Enhance Social Engineering Testing 

Before conducting social engineering penetration testing, it’s crucial to define objectives clearly so you can maximize the value of your test. Here are some questions to consider for successful social engineering testing:  

Phishing and Vishing Penetration Testing 

1. What is the biggest concern you are trying to protect against? 
2. Are you already conducting phishing or vishing campaigns in-house or through a third-party service?  
   • If so, how often? 
   • Have you noticed any trends in failure rates, either higher or lower?  
3. If so, how do these trends inform your readiness for more advanced testing? Are there existing policies or processes in place for users to report suspicious calls, emails, or texts? 
4. Which team or department within your organization is most vulnerable to social engineering threats?  
   • Are these teams public-facing or internal only? 
5. How do these teams most often communicate?  
   • Email, phone call, chat message? 

Physical Pentesting 

1. What is the most likely adversary you are trying to protect against? Being specific about this helps tailor decisions around controls. 
2. How would you describe your company culture regarding physical security?  
   • Is tailgating a standard practice? Do employees feel comfortable challenging unknown visitors? Do people lock their workstations before leaving their desks? 
   • What policies and processes do you have in place to enforce these actions?  
   • What kinds of training have your employees received? 
3. How have your assumptions about physical security changed since the pandemic? 
4. What are the most sensitive areas of your building, where security should be the strongest? 
5. What physical security controls do you have in place already?  
   • How much ability do you have to add new controls, or upgrade existing ones? 

Use these questions as a starting point to guide your social engineering testing. Contact The NetSPI Agents for a conversation at any time.  

3 Types of Social Engineering: Phishing, Vishing, Physical/Onsite 

Social engineering testing encompasses a wide range of techniques designed to evaluate an organization’s vulnerabilities to human-centric attacks. From pretexting and baiting to tailgating and spear-phishing, the variety of attack methods is extensive. For a comprehensive overview, read Tech Target for the different types of social engineering attacks.  

Here, we’ll focus on three specific types of social engineering testing that NetSPI offers:  

• Phishing 
• Vishing 
• Physical pentesting 

Phishing 

Phishing tests involve email and text-based attacks to gauge employee awareness and identify procedural gaps. Campaigns can range from general security awareness to targeted spearphishing attacks aimed at compromising specific accounts. 

Vishing 

Vishing involves phone-based attacks designed to extract sensitive information. During these engagements, the tester may pose as a help desk employee or vendor to gather user credentials, internal data, or customer information. 

Social Engineering Best Practices: Phishing and Vishing Prevention 

• Assume Phishing Will Happen: Acknowledge the inevitability of phishing incidents, especially in large organizations; with thousands of employees, it’s statistically likely someone will click a malicious link. 
• Implement Strong Technical Controls: Establish robust security measures to mitigate the impact of successful phishing attacks, including multi-factor authentication (MFA) to add an extra layer of security. 
• Limit User Access: Enforce strict access policies to control entry points, preventing unauthorized access from non-corporate devices or unfamiliar locations. 
• Streamline Reporting Processes: Create an easy, user-friendly system for employees to report suspicious activity and phishing attempts, minimizing reliance on traditional help desk procedures. 
• Verify Identities: Encourage staff to confirm unexpected communications via secondary methods, such as sending a quick message through internal communication platforms to verify authenticity. 
• Conduct Regular Training: Regularly remind employees of the importance of identity verification and protocols for handling suspicious messages, fostering a culture of vigilance without fostering a climate of fear. 

Physical Pentesting 

Physical tests assess the effectiveness of on-site security measures. This includes evaluating physical access controls, employee awareness, and compliance with security policies. The goal is to minimize the risk of unauthorized access to sensitive areas. 

On-Site and Physical Security Best Practices 

• Focus on Physical Security First: Social engineering is a highly effective way to gain unauthorized access to physical locations. However, if an attacker can simply slip through an unlocked side door without having to talk to anyone, they will likely do that first. 
• Establish Verification Processes: Implement a defined process for employees to verify each other’s identities, especially for new or unknown employees requesting assistance. This can include additional verification methods beyond just badges. 
• Awareness of Tailgating Risks: Acknowledge that tailgating is an effective method for unauthorized entry into facilities. Create awareness among employees about this tactic and encourage vigilance. 
• Encourage Communication: Promote communication among employees for confirming requests made by unfamiliar individuals, enhancing the overall security of the workplace. 
• Provide Regular Training: Regularly train staff on security protocols and situational awareness to empower them to take initiative in verifying identities and reporting suspicious behavior. 

Enhance Your Social Engineering Testing with NetSPI 

Social engineering remains the top method for breaches, because humans are the unknown variable in what’s theoretically a secure system. Prioritizing social engineering penetration testing and prevention is essential to enhance your company’s security posture.  

By implementing strategies focused on equipping internal teams with the knowledge and processes to combat social engineering threats, you can build a resilient defense strategy against these persistent attacks. 

If we can leave you with one key takeaway, it’s this: don’t wait for a breach to happen before you realize the importance of social engineering prevention.  

We’re here to help you take proactive steps today to secure your organization. Explore NetSPI’s social engineering services and contact us to strategically advance your approach. 

The post Ask These 10 Questions to Enhance Your Social Engineering Testing appeared first on NetSPI.

At NetSPI, we help our clients secure their applications, networks, and organizations against a broad range of attacks. Technical controls such as secure coding, configuration, and monitoring are all important parts of the security puzzle. However, as we demonstrated in a recent engagement, even the most sophisticated controls can quickly become irrelevant when they meet the real-world complexities of human interactions. What happens if an attacker can impersonate an employee or influence your employees to take dangerous actions?  

To address these types of risks, NetSPI performs social engineering penetration tests.  Through emails, phone calls, and in-person interactions, testers attempt to gain access to sensitive information and locations. Testers may impersonate customers, other employees, or almost anybody they need to get access. The purpose of these tests is not to fool, or “gotcha” employees, but to expose systemic issues in security policy or training which an attacker might exploit.  

In 2021, NetSPI performed an on-site social engineering penetration test against a high-security datacenter, which resulted in high-impact findings for the client. We hope sharing the details about this engagement will demonstrate how a little creativity and preparation are sometimes all that’s required to gain access to otherwise secure data.  

The Mission 

The client owned and operated an entire datacenter, the building it was in, and the grounds it sat on. They had put significant resources into hardening their security and wanted to understand how an attacker might attempt to physically breach the building and gain access to the data on the servers inside. We were given the authorization to perform pre-arrival social engineering via phone or email, with very few restrictions on what types of pretexts or techniques we were allowed to use.  

That was the good news.  

As we learned more about the location, the bad news piled up quickly. 

1. This was a minimally staffed building. Only two employees regularly work on-site, in addition to a third-party security guard.
2. The building is fully enclosed in an 8-foot-high barbed wire fence, with a single gate. Accessing the parking lot requires a badge scan, as well as a security code.
3. All the building doors, interior and exterior, are protected with badge readers, retina scanners, and security-guard controlled man-traps which require one door to close before the next will open. We needed to bypass these controls before even getting face-to-face with a human, and tailgating was going to be next to impossible.
4. This was an expedited engagement. We had less than one week to research the location, develop our pretext, and prepare. 

Compared to most business environments, this was a very hardened target, and was going to require some real creativity to breach. 

Preparation 

The first requirement for social engineering is a valid pretext. We needed a believable reason to be on-site, one that would give us access to the building.  

Research revealed that the client gives datacenter tours for prospective clients. If we posed as a fake organization, we might be able to get on the datacenter floor, and then break away from the tour to do a little snooping. Open, clear, and detailed communication with the client is critical during every step of this kind of assessment, which was demonstrated viscerally by the reply we received when we presented this pretext to our contact for approval: 

“While I think this is a good ruse, I know the team that will be assigned to give you the tour as you would end up going through our sales channel. The likelihood of your injury or detainment would be high, as I would not be able to pre-warn or potentially stop the person.” 

Thankfully we asked. During a hasty follow-up call with the client, we learned that apparently some of the client’s sales team members take physical security very seriously and have a history of taking situations into their own hands. We added that information to our list of bad news and, with two days before our flights, we went back to the drawing board.  

Real-world attackers aren’t limited by time-boxes. They have all the time they need to research and prepare. Since the timeframe of this test was shortened, we partnered with the client and had them provide us with some basic internal information, which a dedicated attacker would likely be able to obtain either through online research, or observation of the location. Included in that information were the names and email addresses of the two employees who work on-site full time. Also included in the provided information was a list of external vendors who came on-site.  

One of those vendors was a well-known, national pest control company. By lucky coincidence, one of our consultants had recently hired this same pest control company to perform services at their home, and still had all the registration and confirmation emails. Using these emails as templates, we quickly mocked up legitimate-looking scheduling and billing emails for our target location and date. 

Next, we registered a lookalike domain, similar enough to the client’s domain that they could easily be confused. We used this domain to send an email that looked like it had come from Employee #1 and sent it to Employee #2. The email notified Employee #2 of the appointment and asked that the message be forwarded to the security guard. 

The next morning, we got a simple reply from Employee #2:

“OK, thanks!”

Amazingly, the difficult part was done. 

Excited about having our “in,” all we had to do now was sell the pretext while on site. The pest control company we were impersonating has a recognizable brand, and “look” not only for their employees, but also for the vehicles they travel in. We purchased white polo shirts and had the company logo screen-printed on them. We rented the specific type of vehicle used by the pest control company and for extra flourish, acquired die-cut static cling logos for the side of the vehicle. Finally, when we arrived at the destination city, we swung by the local hardware store, picked up some tool bags, flashlights, pest control gear, and rented a ladder. Putting it all together, the result was fairly convincing for being pulled together in two days, and for less than $150. 

Execution

On the day of the test, we simply drove up to the gate with our branded rental truck and used the buzzer. Having been informed of our appointment in advance, the security guard opened the gate with very little explanation required. Employee #2 met us outside and we explained we were there for “winter pest proofing” (whatever that meant). He was expecting us as well, so without further questioning, he swiped his badge, scanned his retinas, and opened the doors for us. Within minutes, we were on the datacenter floor. 

Pretending to look for pests, we moved around the entire building, with our escort using his badge and eyeballs to bypass all physical controls for us. We’ve hunted for a lot of bugs during our careers, but never ones this literal. 

The final layer of physical security between us and the actual servers were cages on the datacenter floor, containing the actual racks of equipment. Our escort declined to let us inside the cages; however, we were able to set up our ladder and get into the ceiling tiles. Up there, data cables from the cages were easily accessible, and it would have been simple to splice network monitoring equipment directly into them or install microphones or cameras. While one tester was taking photos in the ceiling, the other was talking to our escort, eliciting information about the datacenter, their operations, and who their customers were.

After an hour of touring every inch of the building, we announced we had finished our work, and said our goodbyes. This probably would’ve been enough, but sitting back out in the truck, we discussed how we had gotten significant facility access, but wanted to push harder and get onto the network. After a quick discussion, we decided to dive back in.

From the truck, we called our escort and explained that we had forgotten to bring some paperwork we needed to have signed and asked if they had a printer we could use. Our escort agreed and let us back into the building, and even set us up with temporary credentials to access the network. Had this been a full red team engagement we may have tried to pivot to additional network resources, however, the scope of this test was strictly social engineering, so we stayed focused on that. 

After a little contrived hemming and hawing about how to best access the document and print it, we asked our escort if we could just email it to him and have him print it for us. He agreed, and we sent him an email with an attachment, which he was willing to open and print for us. Considering this a sufficient demonstration, we thanked him profusely for all his assistance (and patience) and left the site undetected. 

Evaluation

When evaluating a site’s overall security, it’s tempting to focus on any single employee who assisted us and point out things they personally could have done better, however, that would be a mistake. Not only would it be inaccurate, but it would also derail efforts to improve security and remediate underlying issues. 

In fact, in this case, the employee did not actually violate any company policies at all. He did not allow us to go unescorted on the datacenter floor (despite multiple attempts by the testers to split up) and he didn’t provide access to the actual cages. The information he provided in conversation had some value, but nothing sensitive or confidential. The network access he gave us was on a limited guest network, and opening email attachments is an unavoidable part of doing business, particularly if they came from someone you already know and trust.

The main vulnerability we exploited on this test was the fact that procedures for scheduling and confirming vendor visits were poorly defined. Without a policy or training to lean on, the employee simply received a reasonable sounding request from someone who he took to be his coworker, and then took reasonable actions to assist. He had no reason to suspect something was amiss. 

Ultimately, we did not exploit a flaw in a person, we exploited a flaw in policy.

Final Thoughts and Lessons

In the real world, there is no such thing as an “uncompromisable” target. What would be the point of a box that absolutely no one and nothing can open? Every physical and technical control can be bypassed by someone. Social engineering is, at its most fundamental, the act of finding that someone, and either impersonating them or enlisting their help. 

We have not yet encountered a penetration test where the employee was the vulnerability. Policy training, awareness, and compliance often need to be addressed, but true malice or incompetence is rarer than our natures lead us to believe. When evaluating the security posture of an organization, it’s important to stay focused on systemic issues, and not on individual people.

This test also drove home how communication between the client and the testers is key. If it hadn’t been, the outcome of this test may have been very different, and potentially dangerous. This type of work is not criminal, but it simulates criminal behavior. Criminal behavior involves inherent risks. The best way to mitigate those risks is to reduce surprises. When preparing for an engagement, make as few assumptions as possible, and don’t be afraid to ask for more information.

Similarly, it’s important to understand the difference between a penetration test and a red team assessment. Penetration testing is cool, but it’s not about being a secret agent or a ninja. A penetration test evaluates a specific set of policies and controls to determine if they are functioning as intended. When timeboxes are limited, it’s perfectly legitimate to work with the client to obtain internal information so you can stay focused on what’s important. In technical penetration testing, this is often referred to as a white-box or grey-box test. The same principles apply to social engineering. 

Ultimately, this test demonstrated the high impact social engineering can have, and the relative ease with which it can be used to bypass even the most sophisticated physical and technical security controls. Testing for gaps in training and policy is just as important as testing for gaps in technology. We learned a lot on this engagement and look forward to sharing more in the future. 

Ready to put your policies and security awareness to the test? Work with NetSPI on a social engineering penetration test.

The post Not Your Average Bug Bounty: How an Email, a Shirt, and a Sticker Compromised a High Security Datacenter appeared first on NetSPI.