Safe Digest New Year Edition: "bot" among "friends", bushido against fraud, TB of leaked "snowflakes"

In 2024, we witnessed a lot of high-profile hacks, leaks, failures, and just funny news from the world of information security. At the end of the year, we traditionally asked Alexey Drozd (aka @labyrinth), our head of security, to share his personal top most memorable information security events of the year.

Hello, I am your aunt (CEO)

What happened: fraudsters stole more than $25 million from a multinational company using a "deepfake call".

How it happened: in January 2024, a fraudster sent a phishing email to an employee of the financial department of the Hong Kong branch of a multinational company. In the email, the attacker posed as the financial director of the British branch and tried to convince the colleague to urgently make a large transfer.

Of course, the employee did not believe it and asked the potential colleague to confirm his identity via video call. The fraudster agreed. According to the victim, several people participated in the "deepfake call" - and they all looked and spoke like colleagues from the British office. This convinced the employee, and he transferred $25.6 million in 15 transactions.

The deception was only revealed a few days later when the employee began to worry about the transfer and contacted the company's head office. Hong Kong police said this was the first case where fraudsters used a group deepfake to deceive.

@labyrinth: In 2024, deepfakes made two evolutionary leaps at once. First, "replacement deepfakes" (when the object is "transplanted" with the voice and face of the "donor") finally became widespread. Replacing images/sounds in real-time no longer requires super-powerful hardware and special skills: simple tools have appeared that work on the principle of "press a button - get a result", and in good quality. This reduces the cost of attacks for fraudsters. Of course, to arrange such a "Truman Show" for the victim, as in the described case, the attackers are unlikely to have made deepfakes on the fly - but the problem is that for "hunting" simpler targets, such efforts will not be needed. Therefore, the number of incidents according to the fakeboss scheme and its adaptations is growing and will continue to grow.

Secondly, "generative deepfakes" have made a powerful leap forward. A revealing incident: a Reddit user was able to generate a verification photo (a girl with a driver's license) using a neural network. To my knowledge, this is the first time a neural network has synthesized such a credible fake. The problem here is that the process can be automated. Assign a script or chatbot to write prompts according to a successful template and "stamp" hyper-realistic images of people and documents (!). Then, to deceive remote verification in a conditional car-sharing service (and many other services, including financial ones), fraudsters will not have to look for and buy leaked passports, licenses, etc. And in the future, services will have to revise verification mechanisms: check photos of documents against databases, connect biometrics until they learn to massively fake it, involve live people to confirm the identity of clients, and so on. It will be interesting to watch this.

Botification

How it happened: in February 2024, before leaving Gizmodo, Tom McKay left a "Chekhov's gun" to prank his former colleagues. Tom shared the results and details of the prank on his account in a certain "chirping" social network.

The basis of the idea was a corporate account in Slack and the built-in Slackbot chat bot. Just before being fired, Tom changed his profile name to Slackbot and his avatar to a picture resembling a more evil version of the real chat bot logo. At the same time, Tom bypassed the platform's ban on identical usernames by replacing the "o" in the profile name with a similar Unicode character. This allowed him to avoid having his account deleted. Most likely, the administrators thought that one of the colleagues or Tom himself had already deleted it.

Then Tom started communicating with colleagues as if he were the chat bot. He sent them requests for account passwords, sent notifications that he (Tom) was locked in the computer, or just joked. But none of the former colleagues noticed anything unusual. When Tom got bored, he revealed himself.

@labyrinth: It's funny how even large and well-known services are not immune to "childhood diseases". For example, here Slack fell into a trap known since time immemorial - for example, cybersquatting and the creation of phishing sites are literally built on the substitution of characters in the account or domain name. And at the service level, this is "treated" by simply checking the input data: prohibiting the use of homoglyphs, Unicode characters, etc. when registering a name, which in theory will allow bypassing the platform's ban on identical nicknames. But it often happens that the simplest things are often neglected - and a breach appears in the product. And there will always be a "Tom" who will test the system for strength - and it is not a fact that he will stop at a joke.

Natasha, wake up, you're being DDoSed

What happened: the cat warned the programmer about a night DDoS attack.

How it happened: in April, a certain Danny Guo in a personal blog told about an interesting case from practice - and the story went viral. According to Danny, "a couple of years ago" he worked in an unnamed startup and periodically took night shifts - he and his colleagues took turns monitoring alerts about problems and, if necessary, had to fix them promptly.

During one of his shifts, Danny fell asleep. But by a lucky coincidence, the programmer was awakened by his cat, who came to cuddle with him in the middle of the night. Half-asleep, Danny grabbed his phone – just to check the time. And then he saw alerts from the AWS CloudWatch monitoring service on the screen.

It turned out to be a DDoS attack. Danny noticed that the attack was coming from various foreign IP addresses and simply temporarily blocked all foreign traffic. Thus, a simple coincidence helped to quickly take countermeasures.

@labyrinth: The story about the cat, as if sensing and "warning" about the problem, is filled with cheerful mysticism – because it is embellished, like many catchy stories. In fact, everything that happened is a funny coincidence with a good ending. However, this is also encouraging. If the previous case shows that no one is immune from a simple mistake, then this one shows how an accident can fix the situation. I do not suggest waiting for the intervention of higher powers and "prophetic cats" that will save you from trouble, but somewhere here you can relax a little. Even if you are a "professional paranoid" and work in information security, your task is to reduce risks to an acceptable, controllable level, not to "defeat world evil".

Snowflake Leak

What happened: Snowflake, a company providing cloud storage and analytics services, fell victim to a cyberattack. Clients affected: Adobe, AT&T, HP, Mastercard, and others.

How it happened: In May, the news was abuzz with the breach of the major cloud provider Snowflake. An unknown individual gained access to the cloud accounts of more than 165 company clients and downloaded terabytes of data. Among the affected clients were many giant brands with global names. According to various estimates, this leak could be one of the largest in history. For illustration, only one client – the British bank Santander – had data of 30+ million cardholders and account holders compromised as a result of the Snowflake breach.

After the incident, Snowflake began an investigation and enlisted the help of specialists from Mandiant and CrowdStrike. And then chaos ensued! The versions of how events unfolded are multiplying and confusing.

Some experts say that the hackers first gained access to the Snowflake demo environment using info stealers on the PCs of the provider's contractors. Then, having access to this environment, the attackers could perform actions to discover and extract information from other demo accounts, including client ones. Access to client accounts was also obtained through info stealers, and since the functionality of demo accounts did not provide for multi-factor authentication mechanisms, the hacker was able to easily download corporate data, knowing the login and password.

According to another version, the attacker was able to log into the Snowflake demo account using the credentials of a former company employee. Then the hacker used the credentials from Snowflake client accounts obtained using info stealers. MFA was not enabled in them, and the hacker was able to steal their data without any problems.

Finally, the hacker himself claims that he first hacked one of the contractors of several companies that were also Snowflake clients, then these several companies, and then through their accounts, the entire Snowflake. But even in this case, the key problem was that MFA was not applied in client and demo accounts. This allowed the hacker to freely "walk" inside the compromised infrastructure.

At the moment, the alleged perpetrator has been detained, and Snowflake has updated its account security policy - now MFA will be applied by default for all regular users, and the service will require more complex passwords.

@labyrinth: The situation is one of "nothing is clear, but very interesting." There are more questions than answers. For example, why did most client Snowflake accounts not have MFA enabled? These are the largest companies in the world, yet they make rookie mistakes. Or – why did Snowflake only make MFA mandatory after the incident? It turns out, you see a speck in someone else's eye... If you have "put the picture together," share your version of events in the comments – it would be great to figure it out together 😊.

It will do

What happened: Chinese military personnel handed over secret documents for recycling, which were later discovered by a random person.

How it happened: A Chinese pensioner named Zhang was fond of collecting books. In June 2024, he bought several random books for his collection at a recycling point. At home, he found the labels "Confidential" and "Secret" on them: the books contained secret military documents.

The pensioner reported this to the local branch of the Ministry of State Security. An investigation began. It turned out that two military personnel, Guo and Li, were responsible for disposing of the documents. Instead of following the regulations, they were lazy and sold more than 30 kg of secret documents to a recycling point – for only about $3. The violators were punished, but how exactly is not known.

@labyrinth: How many times have they told the world... – in the sense that many such cases are known. Here is a story about how a flash drive with data on all criminals in England and Wales was lost. Here is about a laptop with an analysis of terrorist plans forgotten on a train. And here is the statistics of the UK Ministry of Defense: in the last two years, 361 laptops, 98 mobile phones, 70 computer hard drives, and 50 flash drives with classified data have been lost or stolen. And this is just one department in one country – and the problem is everywhere. Secrets are lost, forgotten, improperly disposed of (google, for example, "documents/data in the dump", there will be countless links with stories), and no one is immune from such carelessness.

It is surprising that the problem is often found in institutions with the strictest secrecy policies. This once again reminds us that the strictness of the regulations itself does not save from incidents. If it is not followed, there will be no security. Therefore, in addition to implementing rules, it is necessary to think about ways to control their compliance.

Friendly Fire

What happened: a defective CrowdStrike update caused millions of "blue screens" worldwide.

How it happened: CrowdStrike is an American cybersecurity company. It deals with endpoint security, and its flagship product is the Falcon platform. On July 19, 2024, CrowdStrike distributed an update for this platform among its clients. But due to an incorrect configuration file responsible for checking named pipes, all Windows computers displayed a blue "screen of death".

According to CrowdStrike, they quickly noticed something was wrong and suspended the update distribution, but the packages that were already "flying" to clients could not be returned. As a result, about 8.5 million computers were out of order. Many companies had to stop or limit their operations. For example, 5078 flights were canceled worldwide, which is 4.6% of all scheduled flights.

After the incident, CrowdStrike released a patch, but it could not be installed centrally, requiring physical presence at the PC. The vendor also offered its partners and integrators UberEats coupons as a thank you for their help. However, because the coupon was used too often, it was disabled by Uber and caused a new wave of ridicule towards the company.

@labyrinth: since the Solar Winds case, it has become clear that problems with a contractor threaten problems for the client company. And here no hackers or insiders were needed, CrowdStrike developers managed on their own and "laid down" more than 8 million PCs. The additional piquancy is that this is a contractor in the field of information security: the safety of clients depends on it in every sense, and in this they rely on the vendor twice as much. It turned out to be an extremely painful "friendly fire".

Speaking of this, it is worth remembering an important rule: you cannot put all your eggs in one basket - that is, depend on one vendor or contractor. Therefore, it must be said that most large companies usually have several systems even within one class, for example, several different DLPs. Diversification "saves lives". The second point is competent patch management. Do not "roll out" updates of critical software immediately on the entire infrastructure, even if you trust the vendor very much. Develop a plan and act in stages. And be sure to wait for a stable, verified build.

Smoking kills (your connection)

What happened: an employee was in a hurry for a smoke break, so he accidentally "left" half of Africa without the Internet.

How it happened: in August, the British The Register published a column "from a reader", whom the publication introduced as Payton. In it, a former engineer of a large South African Internet provider told about his legendary failure, which happened "several decades ago".

His job responsibilities included maintaining access control lists (ACL). One day, Peyton received a task from management that required some changes to the ACL. According to the former engineer, the task was easy, but then his colleagues invited him for a smoke break. He hurried to finish the job quickly and accidentally deleted some information from the ACL "on the run". As a result, residents of most countries south of the Sahara were left without the Internet. Moreover, unknown individuals took advantage of the situation and claimed that the provider had been hacked.

@labyrinth: The "bottleneck" problem, when the stability and security of processes depend on one dubious element, is very common and manifests itself in different ways. For example, the case of the bank immediately comes to mind, which stopped working due to dead batteries - all the bank's data center systems operated with time synchronization on radio clocks, and as soon as they ran out, everything "collapsed". This story is slightly different, but the meaning is the same. If the system does not have "foolproof" protection (automatic operator action checks, additional confirmation of critical actions such as mass data deletion or function disabling), then the entire system is a colossus on clay feet, and situations like "I pressed something and everything disappeared" are inevitable. I hope this Internet provider has revised its internal processes over the years since the incident so that the stability of its services does not depend on the attentiveness of a single employee. And since there is an opportunity to remind: smoking is evil 😊.

For the love of art

What happened: a ByteDance intern sabotaged the development of neural networks.

How it happened: In the summer of 2024, a man named Keyu Tian started an internship at a large Chinese neural network training company. But instead of working, he methodically and purposefully made his colleagues' lives hell.

Tian added errors to the code, changed checkpoints (AI training save files), and model training parameters. Sometimes he even stopped the training process by uploading Pickle files with malicious code. As a result, a team of 30 programmers worked in vain for two months. In the end, when all deadlines were missed, and the customers' money (as well as the entire team's nerves) were hopelessly spent, the saboteur was identified by the logs.

The story of the Chinese "Skynet fighter" became known to the media in October: ByteDance acknowledged the incident but emphasized that it was "exaggerated." However, by December, the company had already filed a lawsuit against the former intern for 8 million yuan ($1.1 million). Quite an impressive amount for compensation for "exaggerated" damage, right?

@labyrinth: Tian's story is a unique case. Without any apparent reason, it seems he simply "for the love of art" disrupted a major project in a large company. However, it is noteworthy that no matter how he disguised himself, gained trust, and pretended to work hard – he still acted quite "bluntly." This is again a story of how neglecting the simplest rules: controlling "newbies," not allowing unverified personnel to critical processes – led to massive problems. I hope after the trial the world will be told whether the intern was the new John Connor or had more down-to-earth motives. In the meantime, we remember Occam's principle: the simplest solution is often the correct one, user rights control and supervision of newcomers really work.

Honorably

What happened: employees of Japan's Shikoku Bank pledged to commit seppuku if it was found that they were involved in financial fraud.

How it happened: in November 2024, a news article was published on the Shikoku Bank website in the "investor relations" section. In it, the company reports that its employees literally signed a "seppuku contract" in blood.

It says that if a "bank employee steals funds or forces others to do so, they will pay for it with their property, and then end their life through the seppuku ritual." Noteworthy is not only the part about seppuku but also about the property. Employees are obliged to compensate the client by selling their real estate, cars, etc.

@labyrinth: The case is almost anecdotal - both curious and extremely undesirable to see an internal incident in the company and the contract has to be fulfilled. Although there is logic: when the stakes are so high, only a few will dare to break the rules. This is a huge motivation to follow the rules. In Russia, for example, since last year, there has been personal - criminal! - liability for IS managers for incidents under Decree No. 250. Here you involuntarily want to joke: just so that the Japanese example does not inspire tightening. But in truth, the "stick method" works - and we also have a relative "carrot" in the law on turnover fines, where good IS equipment mitigates liability for personal data leaks.

Finally, I would like to wish that IS incidents remain for you only amusing reading in such collections. And for us - to hope that such collections will become more difficult to compile: due to the complete absence of news about someone being hacked and something leaked. Congratulations on the upcoming holidays! May 2025 be cyber-safe 😊