Cheese Movers International’s restructuring resulted in some employees being unhappy with either their new role or the new management. And unhappy employees, especially those who know the system well and have access, can become major problems for companies.
Verizon’s RISK Team was called in because the multinational company had heard rumblings among the disgruntled employees and found some negative comments online. While there was no evidence of a data breach, Cheese Movers' upper management was concerned something was coming.
This is just one case found in Verizon’s recently released annual breach report, which examines some of the cases where the RISK Team was called in to hunt down culprits. The “ride–along edition” of Verizon’s report provides a first-person perspective of the company that calls in the heavy hitters to find out why the network has slowed, who defaced a website or where a leak is coming from. With all the accounts, the names of the companies have been changed to protect the brand from public ridicule.
The RISK Team performs cybersecurity investigations for hundreds of commercial enterprises and government agencies annually across the globe. Over the previous three years, they conducted over 1,400 engagements for their customers. Here are a few of their reports:
Not moving on
Cheese Movers International (CMI) had drawn the attention of more than one group of hacktivists who had posted messages on their social media accounts referencing the company's organizational changes. Various derogatory hashtags on social media were popping up and threats against executives were being posted to social networking sites, according to Verizon’s report.
CMI’s precarious situation was exacerbated by the risk of an insider or recently terminated employee using their advanced knowledge of the organization to perpetrate an attack or to leak information to would-be attackers.
Verizon initially provided CMI with assistance and guidance in collating and reviewing open-source intelligence; this included searching social networks and online forums as well as specialized investigative activities within the darknet. They set up a secure anonymous account, which enabled Verizon’s crew to search through marketplaces and other locations on the darknet to see what the hacktivists were discussing in relation to CMI. These activities identified many threats and negative statements. And although most of the discussions were not considered genuine threats, the home address and personal details of executives were being actively sought by suspicious parties, Verizon reported.
The breach of personal information associated with senior executives was identified early enough that it could be reported to law enforcement. This was just the first of multiple threats and attacks experienced over the course of the next three weeks. Distributed denial of service (DDoS) attacks were attempted against many of the company’s websites (the majority of which were thwarted by the DDoS protection capability that CMI had put in place).
The pen testing team performed urgent assessments of key assets and identified vulnerabilities in web-facing servers that could have proven catastrophic had they been noticed by hacktivists. In two cases, a SQL injection vulnerability and an unpatched application with known vulnerabilities were identified. It was later found that both servers had been targeted with reconnaissance activities.
After about two weeks of defending against attacks on all fronts, an attack was finally successful. One of CMI’s websites appeared to have been defaced: The site was not accessible and had been replaced with a message claiming responsibility and blaming CMI for inviting this retribution. The posted message claimed that CMI's servers had been hacked and customer data would be leaked unless certain actions were performed. Verizon determined the defacement was not the result of a compromised system, but rather the website's URL was being redirected to another server hosting the message.
It was later determined that the domain registrar for the effected domain had been targeted in a social engineering attack, during which the threat actor successfully impersonated CMI staff. They were able to gain access to the account on the domain registrar’s service and modify the relevant DNS records, which caused visitors to the CMI website to be redirected to another website.
The affected site was not CMI’s principal website and was only used by a small subset of its customers. The DNS issue was quickly resolved and the affected domain was migrated to CMI's principal domain registrar, whose security practices were superior.
- Don’t rock the boat. Stay off the radar of any potential hacker.
- Keep an ear to the ground. Base defenses, detection mechanisms and response capabilities on sound threat intelligence.
- Secure your environment. Implement a timely and effective patch management program; conduct regular penetration-testing activities.
- Protect social media accounts. Use two-factor authentication, strong and varied passwords, as well as proper security awareness training for staff members who manage the social media presence.
- Protect third-party services. Protect account credentials; use a reputable domain name registrar that offers two-factor authentication or approved IP address whitelisting.
- Prepare and initiate your incident response (IR) plan. Establish an IR plan early, and then regularly review, test and update it.
- Scope and triage the incident quickly. Effectively scope and task prioritize; be prepared to manage simultaneous, yet distinct, incidents.
- Proactively communicate with affected entities. Confirm facts quickly; develop a remediation strategy and communicate this to customers.
- Engage law enforcement at the right time. Consider legal and regulatory responsibilities in conjunction with advice from legal counsel.
Down to the wire
Here is another Verizon case from their client’s CIO:
“I asked in this day and age, how is it even possible for threat actors to initiate fraudulent wire transfers?”
Verizon's RISK Team investigative response liaison replied, “It happens all the time. Threat actors use social engineering tactics to fool someone into processing a fraudulent wire transfer.”
“I thought, sure, it happens all the time, but this couldn’t possibly happen to us. After all, as the CIO, I provide written approval for all wire transfer transactions within our organization. I was confident we had enough checks and balances in place to avoid fraud occurring,” the CIO said in the report.
One day the finance director came to the CIO’s door with a manila folder in hand. She proceeded to say that as part of a monthly audit, the finance department was missing an international tax form for a wire transfer that had occurred three weeks prior. This missing form had prompted her to request it from the accountant who originally submitted the request for the wire transfer.
“When she asked him for the form, he could not recall the details of the transfer. Since I had approved the transfer, she thought she would ask me if I could offer some assistance in ‘jogging his memory,’” the CIO said.
As part of the company’s wire transfer process, the accounting team must first email an invoice to the CIO containing the company name, services provided, bank account information and invoice amount. The CIO reviews the invoice and replies by email with an “approve” or “deny.” If approved, the accountant then forwards the email, invoice and tax form (if applicable) to the Wire Transfers Department. This department then reviews the information for accuracy and processes the wire transfer.
In this case, with the exception of the accompanying tax form (which isn’t required immediately upon completing the wire transfer) all of these things happened — except the CIO, too, could not recall providing the approval for this wire transfer. The finance director showed the CIO the email in which he approved another wire transfer to the same bank account just three days prior to the one in question.
“We weren’t talking chump change here: This was a significant amount of money, like buying a Rolls-Royce Phantom in a couple of different colors kind of money,” the CIO said.
The RISK Team examined the email header information and confirmed that the wire transfer request did come from the accountant’s internal corporate email address. However, they noticed the purported CIO’s email address was off by one character. Verizon explained that it was originating from an external email service. The RISK Team confirmed someone had registered a domain very similar to their client's just a few days before the wire transfer emails were sent.
“We now knew how the threat actor was able to provide the approval email, but I still wanted to know how the emails originated from the accountant’s corporate email account,” the CIO said.
The RISK Team collected the accountant’s email archive, a memory dump from the accountant’s laptop, and a forensic image of the laptop hard drive. The RISK Team asked for email web access logs. Verizon reported that numerous external IP addresses had been successfully logging into the accountant’s email using email web access. These logins started about a week prior to the wire transfer requests.
By analyzing activity on the accountant’s laptop at the time of the web email logins, the RISK Team was able to determine the accountant had received a phishing email from someone claiming to have paid a late invoice. The email instructed the accountant to click a link and provide their email domain credentials to authenticate and review the payment receipt.
Apparently, the accountant provided his email account credentials and then forgot to follow up on the fact that he didn’t receive the payment receipt. The threat actor used the accountant’s credentials to log into his email account and study the company’s wire transfer approval process by searching through emails. The threat actor even used previously sent invoices and tax forms to create the fake versions that were used for the fraudulent wire transfers. The threat actor fabricated an approval email chain that was sent to the Wire Transfers Department, according to Verizon’s findings.
The company was told that the link contained in the email was known to be malicious. “I really started to wonder why our tools didn’t block access to the URL,” the said.
It turns out the internal URL filtering tool did block access to that URL from other systems within the network. It didn’t block it in this situation because the accountant had been connected to his personal Wi-Fi network. He was working from home the day the phishing email was received. The IT Security Team said the company’s tools weren’t able to block the URL because the accountant wasn’t using the corporate network.
“To this day, we are still working with law enforcement to figure out what happened to our money,” the CIO said.