Social Engineering To Breach Global Company
Overview
This social engineering case study shares how we were able to breach a global company using some remarkably simple techniques. It shows how easily someone can become a victim of social engineering with only a few pieces of information, a little persuasion and touch of emotional manipulation.
What Is Social Engineering? Social Engineering is a tactic used by individuals to manipulate and deceive others into disclosing sensitive information or performing actions that they would not typically do, through persuasion, influence, and emotional manipulation.
Context
Netragard was engaged by a large multinational company to assess the security of their internet-connected devices and applications. The primary goal is infiltrating their network and gaining control of critical assets without detection.
We began our penetration test with passive reconnaissance using third-party services such as Shodan, Censys, and DarkOwl. These services regularly scan the internet and darknet. This enabled us to get a clear understanding of what technology was being used at the company. Known vulnerabilities and how those technologies are configured, as well as detailed data about employees’ work and personal activities on the internet would be revealed.
Identifying a Target
The research revealed that the customer’s external infrastructure was minimal in terms of connectable services, despite its large size. It was clear these services were protected from a monitoring perspective and properly maintained from a patching/configuration perspective. The chances of an attacker directly breaching any one of these targets in a covert manner was low unless the attacks were spread out over an extended period. Therefore, because keeping a low profile was a crucial aspect of our objectives, we needed to identify other paths to compromise. It was imperative that we avoided areas with a high risk of detection.
Information gathered on employees revealed variations in their roles and responsibilities. We were able to identify a small group of employees who would be most beneficial in facilitating a hypothetical, irrecoverable compromise of the client’s infrastructure – and then ultimately, deciding on a single target employee that was one of the client’s trusted and respected IT security employees. We will refer to the target as Sam.
Given Sam’s job responsibilities and level of experience, it was likely that targeting him directly would not be successful. We surmised that his role would make him less susceptible to social engineering tactics, especially phishing and vishing. Nevertheless, we recognized that it was still possible to use social engineering indirectly to compromise Sam’s access. To achieve this, we sought help through the client’s Helpdesk, as it would enable us to impersonate Sam.
Information Gathering
Prior to being able to socially engineer the Helpdesk staff, we learned what processes and procedures were in place; particularly how employees were verified before receiving helpdesk assistance. We did this by placing exploratory calls to the helpdesk over a two-week period. This process produced actionable intelligence that explained how to socially engineer the Helpdesk & also what time/day they were susceptible. We established that the after-hours staff did not always authenticate users as they should. This was especially true when a user was frantic or under pressure.
Launching the Attack
With this knowledge in hand, we decided to launch our attack on a weekday at 9 pm. A call was made to the Helpdesk. We introduced ourselves as Sam (the real employee) and explained our situation with a panicked and urgent voice. We explained that we were unable to access the company network and had to complete a project by the next day. When we were asked why we could not access the network, we explained that we left the office in a rush due to a family emergency and in the chaos, we lost our cell phone while in transit.
Then we stressed that we no longer had email access, calendar access, nor did we have access to authenticator app that was installed on the lost phone. To create more urgency, we told the Helpdesk engineer that we had a project to complete by the next morning and would likely lose our job if we could not get it done.
Helpdesk Engineer
The Helpdesk engineer skipped the authentication process like we had hoped, and went right into helping Sam. The engineer was compassionate, told us we should not worry and that he would resolve our problem. The first thing the engineer did was to help us reset Sam’s password. To do this he had us browse to a specific website that prompted us for our username, password, and one-time password (MFA). We did not have those, so the Helpdesk engineer provided us with a temporary password and code to bypass MFA. Once authenticated, we were able to reset Sam’s password to something complex and secure.
Next, the Helpdesk engineer walked us through setting up a new phone for MFA. They provided us with a URL to download and install the application, and the necessary information to configure and enroll our telephone with their authentication service. At this point we thought we were done and were ready to move forward. However, the helpdesk engineer continued to assist and asked us to open a web browser and authenticate to their remote access system. This was the first time we heard about this system so we pretended we could not remember the URL. True to form, the Helpdesk engineer provided the URL to us, then we logged in, said thank you in an excited and happy manner, and ended our support call.
Exploiting the Information Obtained
When we logged into the remote access solution, we saw the choice to connect to different computers. We arbitrarily clicked on the first one which automatically connected us to Sam’s desktop. As soon as we connected, we noticed a web browser that showed authenticated administrative interfaces for AWS, Azure and M365. We were able to confirm access by navigating the interfaces while taking special care to not to make changes other than creating Netragard user accounts to prove access to the customer.
At this stage of the engagement, we thought it necessary to inform our client of our successful intrusion to gain control of critical assets without detection. Initially, they were skeptical because no alerts were triggered, and no unusual activity was detected. To confirm the compromise, we directed them to the Netragard accounts we had created. Upon realization of the gravity of our access, they expressed their appreciation for our efforts, but were perplexed as to how we achieved this without detection.
When attackers are able to compromise & operate from legitimate user accounts, particularly administrative accounts, their activities don’t usually generate alerts. Additionally, we highlighted that by utilizing passive reconnaissance techniques and social engineering, we were able to avoid generating any traffic on their network until we reset Sam’s password and authenticated it to their remote access system.
Key Takeaways
- Regular training and testing should be mandatory for all personnel with access to an organization’s infrastructure. This should include routine phishing exercises and advanced social engineering simulations at least once a year.
- Organizations should be aware of the potential for indirect attacks and take measures to protect against them. An example of an indirect attack is when Netragard was able socially engineer the Helpdesk to target a specific user. Another example would be reconfiguring a compromised printer to authenticate to an attacker-controlled SMTP server to capture its credentials.
- Establish a policy to always terminate administrative sessions when they are not in use.
- Establish a process for sending alerts via text or email when privileged user accounts are accessed, as this is a simple yet effective method for detecting the type of attack as described above.
- Establish a method for authenticating users before they are serviced by the Helpdesk.
- When a user contacts a Helpdesk, the Helpdesk should always send an email to notify them about the case and to enable them to track the case. This also makes it difficult to impersonate someone as we did above.
If your business is concerned about the threat of social engineering attacks, reach out to our cybersecurity experts at Netragard. We have the knowledge and experience to help you defend against these types of threats and keep your business safe. Contact Us today to learn more about how we can help.
