Just to kick things off. Here’s an article describing scammers using phishing techniques netted 11 million Canadian (9 Million US).
The article says this is not technically hacking. I don’t agree, but what do you think?
For those with an audit background, it also points out that anti-fraud controls were either not in place, or not effective.
Anthony Wong says
Although the scammer did not compromise any systems or obtain any sensitive information, in my mind it is still a hack because vulnerabilities around the University’s controls and processes for changing vendor’s banking information were exploited for personal financial benefit. The scammer was able to accomplish this hack through deception and manipulation of the University’s staff. It would be interesting to see where the gaps were in the University’s process that lead to this mishap.
Kelly Sharadin says
Hi Anthony,
I agree, its unclear to me in the article whether one employee or multiple employees are responsible for the transference of funds. Examining “the how” this happened would change depending on those involved. Was it one employee who failed to thoroughly investigate the email before entering credientals or were multiple employees failing to do so?
Nicholas Fabrizio says
I would also agree that this was hacking. Even though the attackers did not again access to any of the universities computer systems they were able to exploit a vulnerability in the university by deceiving the staff to change payment details for a vendor. Employees tend to be the weakest link in cyber security. In my opinion, changing payment details would violate integrity in the information security main objectives (CIA). I believe the university should look at their security awareness training for employees to help mitigate future phishing scam attempts.
Kelly Sharadin says
I think the article’s language of “not technically a hack” illustrates two possibilities; the author’s misunderstanding of what a hack is and possibly some PR management by the University. Sure, termanology matters when we’re discussing the difference between a hack and a breach or an incident versus an event; however, there’s no speculation here. This was a successful phishing attack that resulted in the University publicly losing millions of dollars. Had the employees not re-routed the money, then technically it wouldn’t have been a hack. It also demonstrates a lack of due diligence on the University’s end, a simple phone call with the vendor to verify the change in information could have mitigated the attack as well.
Amelia Safirstein says
I agree with you that this incident does qualify as a hack as the attacker used a computer/phishing attack to expliot weaknesses in the company’s processes. It does open up the question: where does simple con-artistry or simple theft turn into hacking? Does the hacker have to be behind a computer? If a malicious actor dressed up in a delivery uniform, took advantage of an entryway security system by piggybacking, then walked out with some super expensive painting, would they be considered a hacker or simply a thief?
Bryan Garrahan says
“According to the university, the attacker sent a series of emails that convinced staff to change payment details for a vendor, and that these changes resulted in the transfer of $11.8 million CAD to the scammer.”
This part of the article made me curious as to how the attacker was able to pull this off. Did the attacker utilize a personal email in order to request the payment details? Or perhaps did they somehow obtain a vendor user’s credentials in order to submit the request? If the latter, this too would be considered a hack along with the exploitation of the University’s employee(s). A few thoughts in terms of controls:
– I believe there was likely little to no control around the process if the attacker was able to use a personal email in order to successfully submit the request.
– Let’s say the attacker was able to obtain vendor internal user credentials and there was some type of approval control around updating payment details. My assumption would be that the control wasn’t designed effectively. Perhaps requiring a second level of approval within the updating/modifying payment details process could have mitigated the risk of the hacker pulling of the attack.