Check out the on-demand sessions from the Low-Code/No-Code Summit to learn how to successfully innovate and achieve efficiency by upskilling and scaling citizen developers. Watch now.
Live chat has become ubiquitous as a sales and support tool for software as a service (SaaS) or cloud based services. Entire businesses have been built around providing live chat, such as Olark (which my company uses) or Intercom. As the CEO and founder of a SaaS business (Sendwithus.com), I had very little question about if we should support live chat; it was just a question of how to offer live chat to our customers.
Like many enterprise platforms, we support adding multiple team members on an account and setting up user permissions like an account administrator. Early last year we were lucky enough to catch an attacker attempting to social engineer our live chat operator and gain access to a Fortune 1000 customer’s account. I say we were lucky because our typical attitude to support is customer focused, always looking to go the extra mile for a customer. I can imagine that, without certain conditions being met, we could have missed this.
For the uninitiated, social engineering is a form of fraud computer hackers often employ to gain access to information or systems by manipulating employees at their target company. An example of this is the 2013 credit card theft from retail mega chain Target.
In our case, the chat session started innocuously enough:
Intelligent Security Summit
Learn the critical role of AI & ML in cybersecurity and industry specific case studies on December 8. Register for your free pass today.
Attacker: Hi, we have employees in COMPANY who needs access in your portal. Do you manage providing access to our employees?
Us: Ah, you’ll need to get access from an administrator on the account.
This initial question seemed odd, but it didn’t trigger immediate alarm bells with our staff. But the repeated attempts to gain information made us suspicious.
Attacker: hmmm.. and any idea who or how will I know who supposedly this person be?
Attacker: By any chance, you know if COMPANY is tied up or something like that with your company?
Attacker: well maybe for a start, I want to understand the service your company is providing because our employees are requesting access from you portal.
The above are direct excerpts from the chat our support staff had with the attacker. While the questions alone made us suspicious, there were some major warning signs in this interaction. Enterprise customers usually have somewhat complicated internal structures, but we make a very concerted effort to understand who the account administrators need to be and which users will need access to said accounts. The attacker was not one of the managers we were already familiar with, which appeared odd.
Next, our chat service displays which email address the customer is using, and the attacker had specified “email@example.com.” It seemed very odd to us that they would not use their “@company.com” email when talking to our team, given they were an existing customer. Another tip-off was that the IP address that our chat service reported resulted in an IP block within a reasonable proximity to the customer’s’ headquarters.
Finally, if a chat user is logged into a Sendwithus account, their account information will show up alongside the chat window. In this instance, we noticed that the attacker wasn’t logged in at all. Given this information, the team member on chat decided they were uncomfortable offering any information and politely told the attacker to contact their internal administrator.
The day after this happened we sat our entire team down to discuss what exactly social engineering was and what sort of things were appropriate to do on chat. We set out the following guidelines for chat:
1. Trust, but verify. Each chat should start with a warm “hello” and checking if the user is logged in, if we’ve talked with them before, and what account they are associated with.
2. Whitelist acceptable use. Have a very small list of acceptable support items to handle via chat; escalate other requests to email. This keeps chat times quick and secure
3. Always use official channels. Ensure we only offer support via chat, a ticketing system (with dedicated email), or dedicated phone lines (priority support).
4. Not sure? Ask. If a team member is ever uncertain about a customer’s’ request, ask the rest of the support team.
While this attack was fairly obvious, there are common techniques that a more sophisticated attacker would try. Phishing, for example: Be careful about clicking links that customers send via chat or file attachments sent via email. Bitcoin exchange Bitstamp was hacked this way last year — to the tune of $5 million. Malicious attachments were sent to team members, including their head of support.
Alongside phishing, attackers will commonly try to extract private information as part of social engineering. For example, while the contact phone number of an account manager seems harmless to release, an attacker can use that number in the future to fake familiarity with another entity. This is one of the reasons it’s crucial to perform support only through official channels. Employees helping customers via personal email, Skype, or cell phones greatly increases the likelihood of a successful social engineering attack.
VentureBeat's mission is to be a digital town square for technical decision-makers to gain knowledge about transformative enterprise technology and transact. Discover our Briefings.