Mike Talon's Home on the Web

On what I thought would be a rather boring Monday, I opened my various social media pages to find them inundated with the news that government officials, including the Secretary of Defense, spilled details of recent US military movements in a Signal chat channel which included non-government people in the chat. I also had many folks asking me what Signal was, and why those officials would be using it to discuss what was – at the time of the messages being sent – secret military maneuvers. So, let’s dive into the topic:

Signal is an end-to-end encrypted chat application available for mobile devices and many desktop operating systems. Essentially, it allows people and groups to exchange messages with each other that are encrypted from the moment they leave the sender’s device until they reach the receiver(s) devices, meaning that anyone snooping around between the two won’t be able to read the messages. These applications are very popular with security researchers, journalists, and others who believe – or know – that their communications are being monitored, because those communications are indecipherable gibberish to anyone but the sender and receiver. In the case of Signal, the sender(s) and receiver(s) of each individual chat or group use unique encryption/decryption keys, so not even Signal themselves can read anything sent across the network. This is different from apps like FaceBook Messenger where the company that runs the service can see all the messages, even though no one else has that ability, and adds another layer of security in the event that the service provider gets compromised themselves. 

Normally, the idea that highly-confidential information in a Signal chat was visible to the general public would be a cause for extreme concern, as the sophistication required to even attempt to break the encryption in Signal is significant enough for such an event to be insanely rare at best. In this case, no one had to steal the data and decrypt it, they were invited into the chat directly. Of course, the idea that such information was being shared in a 3rd-party, non-government managed applications at all was also an extreme cause for concern all by itself. 

A senior editor for The Atlantic (a news magazine) was accidentally added to a Signal chat that included – amongst others – Secretary of Defense Pete Hegseth, members of military groups, and possibly the President himself. How this happened is being investigated but the current best guess is that Jeffrey Goldberg (the editor) was added by accident when someone attempted to add a different person entirely that had a similar name. Signal accepted the request to add Mr. Goldberg and added him to the chat and provided the necessary decryption protocols, meaning someone completely outside of the US Government could now freely read information about highly sensitive military operations no matter if he wanted to or not. To his credit, Mr. Goldberg did not publish information about ongoing operations, but waited until that information was made public through official sources before publishing the story of how he was able to see it well before that point in time. One such piece of information was the recent bombing of Houthi rebel targets in Yemen – information which could have spelled the absolute failure of the operation if it had been leaked – so I give Mr. Goldberg credit for his holding the story back until it couldn’t derail actual military events. 

Some questions I’ve gotten on the story, and the best answers I could find:

 – Is Signal safe? Yes, for the most part. Barring any accidental adding of magazine editors to chats, Signal is generally acknowledged to be a safe and easily utilized communications application. 

 – Can government employees even install Signal? This one is a bit complicated to answer. The simple version is that there are some government agencies where the application is not permitted, but for the most part it is allowed on the personal devices of government officials.  

 – Why was anyone discussing highly sensitive – or potentially even classified – information on a chat app? We don’t have the answer for this one yet. Humans will do odd things sometimes, and apparently one of those odd things is to discuss incredibly sensitive topics in a commercial chat app that isn’t managed by the US Government on devices that are also not managed by the US Government.

 – Exactly what got sent to the reporter? According to the Atlantic article, the Secretary of Defense sent the details of the bombing strike against the Houthi rebels about two hours before the strike began – and then various participants in the chat continued to discuss the operation as it occurred. 

 – What happens now? The US Government will have to undertake an investigation into three key topics:

 1 – Why were officials discussing this stuff on Signal instead of through official US Government tools?

 2 – Who invited Mr. Goldberg into the chat – accidentally or otherwise?

 3 – Why didn’t anyone realize a member of the press was sitting in said chat?

It will no doubt be some time before we find out exactly how this happened. It will also most likely lead to several resignations and high-profile firings. I’ll try to update the story as more information is made public.

UPDATE – March 24, 2025 – Mr. Gordon apparently held back some of the chat logs from Secretary Hegseth and others that he believes contained information about upcoming military and government operations.  While we will never know if this information is considered “Classified,” it is most definitely highly sensitive and should not have been shared outside of US Government information systems. 

A reader recently asked, “What is DeepSeek, why am I hearing about it everywhere, and is it a cybersecurity threat?” In order: An AI platform, money and politics, and most probably yes. Let’s dive into this and try to make some sense out of the sensational headlines. 

DeepSeek itself is an Artificial Intelligence (AI) platform produced by a company owned by High-Flier, a Chinese hedge fund/investment company. While the official name of the company is private, it has come to be known internationally by the name of its flagship product, and we’ll refer to them in this article as just “DeepSeek.” While the company is not owned by the Chinese government, as a Chinese company the government has significant influence over the company, its products, and any of the data it collects – meaning that while the platform isn’t a government-owned entity, it might as well be. This becomes important later when we discuss the potential privacy issues that the platform poses. 

DeepSeek is a multi-use platform based on Large-Language Model (LLM) operations. The first product they have released is a chatbot – a Generative Pre-trained Transformer (GPT) tool similar to ChatGPT from OpenAI or many of Microsoft’s CoPilot tools. Basically, you can ask the AI a question, and even if it has not been specifically trained on that question, if it has access to enough data it can produce an understandable answer in multiple languages that can be factually correct. I say “can be” factually correct, because if the LLM is trained on bad data, it will give out bad answers; and all LLM’s are susceptible to eventually starting to hallucinate. Hallucination refers to when the AI begins to repeatedly provide incorrect or non-factual answers, and often indicates when the system is beginning to reach the end of its ability to continue operating (reaching the “end of its envelope”). Think of it like a human brain – the more we learn, the greater the chance that we can accidentally get our “wires crossed” and conflate two things that are not related. Just to be clear, as DeepSeek specifically is very new, it has not begun to hallucinate and most of its answers have been factual so far. 

A quick side-bar on AI, since the term is often confusing to approach:

Artificial Intelligence is a blanket term that includes many specialized areas of technology. This can be Machine Learning (ML) that is used to predict outcomes based on large numbers of previous events, GPT systems which can parse input in plain language and supply appropriate output based on massive databases of information in plainly understandable language, and other forms of technology centered around a digital (or quantum) system behaving in a similar way to the human brain. All these sub-groups are AI, but focused on different types of analytics and/or interactions.

You use AI every day: When you visit Amazon, YouTube, or really any other site online; there are ML algorithms that determine what products, videos, or other information gets suggested to you. When you talk to a chatbot on a site to get basic-level help with something, that’s an LLM “reading” your question and attempting to provide an answer – to various levels of success, but getting better.

What makes systems like CoPilot, ChatGPT, and DeepSeek so different is that they were not built with a specific set of subject-matter expertise. They are instead designed to be able to converse with humans on a huge variety of topics – much like a human would be able to talk about what they do for work, for fun, what was in a TV show they watched recently, etc. This makes GPT-type systems extremely useful for organizations that are looking to automate interactions with customers, employees, and other humans. While we’re not at a point where humans can be replaced by these systems, they are very good at “force-multiplying” employees, allowing the same number of employees to handle more calls, emails, and other interactions without becoming overwhelmed. 

In summary, DeepSeek’s first product is a GPT-type AI platform based around a Large-Language Model. You can ask it questions on whatever topic you’d like, and it will nearly always be able to produce a factual, topical answer that makes sense. So, why all the furor over it?

The two primary reasons are money and politics. 

From a money perspective – DeepSeek does not use the hardware that US- or EU-based companies like nVidia manufacture. The ability of any AI developer to build systems without these chips is extremely rare, and sent shockwaves through the technology markets. Because of DeepSeek’s ties to Chinese manufacturers, the ability to built the platform without non-Chinese chips and other components wasn’t a total surprise, but the fact that they produced a system on-par with US and EU competitors like Microsoft CoPilot was a shock to the technology community. nVidia an other companies found their stock prices sharply dipping in the days after DeepSeek launched, and that event may signal a downturn in the financial power of hardware manufacturers specializing in chips that power AI. As such, there are powerful monetary pressures being exerted by multiple companies and governments on all sides – leading to a lot of press coverage and no small amount of controversy. 

From a political perspective, DeepSeek is a Chinese product. The company that owns the company that makes DeepSeek is a well-known Chinese hedge-fund, with significant ties to the Chinese Communist Party (CCP). Because of this, data shared with DeepSeek – including all the user information, all the questions that get asked, where everyone is asking them from, etc. – will almost absolutely be visible to the CCP. This leads to a not-unreasonable fear that confidential or even classified information could end up in the hands of a foreign government who is not precisely friendly to US, EU, and other interests. Based on what we’ve seen end up in ChatGPT, CoPilot, various and assorted AI-generated porn-bots, and many other examples; people share confidential, privileged, or outright illegal stuff with these chatbots – information you do not want in the hands of a hostile government. See the disaster over at muah.ai – https://www.malwarebytes.com/blog/news/2024/10/ai-girlfriend-site-breached-user-fantasies-stolen

This makes DeepSeek a double-whammy when it comes to controversy and media coverage since it impacts both major financial concerns and major political concerns all at once. But what about cybersecurity danger? As it turns out, pretty significant.

There are two areas where DeepSeek is a highly probable cybersecurity issue: privacy and overall security.

From a privacy perspective, it is well known that Chinese companies will – and are often required to – share data with the CCP. This means that all the prompts typed in, usernames, addresses, email info, etc. are almost definitely being shared with outside parties – namely the government and intelligence agencies of China. As you might guess, having whatever questions you’re asking being shared with another government isn’t something a lot of people are comfortable with. On top of that, there are indeed many people in multiple countries who are not tech savvy and will treat DeepSeek like Google – asking it anything and everything. Some of these people may work with highly confidential data (think health records) and/or highly classified data (think military). As has been shown in previous leaks from LLM’s, this absolutely happens, and it’s absolutely a privacy issue at the very least. 

From the perspective of overall security, DeepSeek really dropped the ball. Within 48 hours of it being unveiled to the world, one research group had already found as serious vulnerability in the platform that could allow them to see data in the back-end of the system. Not 24 hours later, another researcher discovered that entire databases of information were visible to the outside world. While that researcher didn’t take a copy of all that data, it’s frighteningly possible that someone else did or will. See https://www.bleepingcomputer.com/news/security/deepseek-exposes-database-with-over-1-million-chat-records/

The fact that two major security issues were discovered in such a short amount of time indicates that the platform was not properly secured before it was launched. The possible reasons for this are varied – from not having the right security folks looking at things to the product being rushed out the door – but the end result is the same. The platform was launched with multiple security issues and inadequate defenses around them. There is a high likelihood that more will be discovered over time, and that data will leak, be stolen, etc. beyond just being shared with the CCP as most sources agree will happen no matter what. 

And there you have it. A combination of monetary and political issues forced DeepSeek to the front pages, and ongoing cybersecurity questions – and the fact that DeepSeek is run by a Chinese company – indicate serious privacy and security issues. While we’re a global society, and not every useful or powerful product comes out of the country we live in, I still would not recommend the use of DeepSeek by anyone until all of these factors are dealt with, mitigated, or otherwise addressed. 

A recent question that I’ve seen in light of this DarkReading article is, “Has Microsoft’s MFA been hacked?” The answer is “no,” but the overall story requires a bit more explanation. Let’s dive in.

First things first, what is AzureMFA? For organizations using Microsoft 365 services, one option available is the use of Multi-Factor Authentication (MFA) to better secure the applications and data stored within those systems. AzureMFA, as it is named, is also available to people and companies using other Microsoft services – and even non-Microsoft services – so it is a popular security tool. When a user logs into an application or website using AzureMFA, they will provide their username and password, but also have to provide another identity token before the login is successful. This token can be obtained in several different forms, but the two most common are the Microsoft Authenticator app on a mobile device, or a six-digit One-Time Passcode (OTP) sent via text message. The Authenticator app can provide OTP’s as well, but opens up more options such as “tap-to-authorize” or requiring a user to match a number on the computer screen to one of several numbers displayed in the app.  

The issue that the researchers from the DarkReading article uncovered applies to OTP’s sent via text message, but could also apply to OTP’s received via the Authenticator App as well. OTP’s are created through a complex mathematical formula that sends multiple variables – like the exact time of the login request and the unique identifier of the user device – through the equation. That generates a six-digit code which will (at least to any human being watching) be different for every login by every user. The problem is that the formula itself doesn’t change, just the variables that are fed into the front end of the equation. There are also a finite number of six-digit combinations, one million to be exact. This lead to the vulnerability the researchers discovered.

So, what happened? By flooding a login request with hundreds of thousands of attempts very quickly, the researchers were able to work out a pattern in the OTP’s that were being created for that user. Eventually, they were able to take things one step beyond that, and anticipate what the next OTP would be. After successfully “guessing” the OTP that would have to be entered on the next login, they realized that this flaw could allow a determined threat actor to bypass the MFA check and gain access to an application with just the username and password of the user – something considered to be extremely insecure these days. 

While this is concerning, keep in mind that this only works if other security controls are not in place for that login process. Most organizations will limit login attempts to a specific number – usually somewhere in the dozens to hundreds – before temporarily locking the user account. These aren’t unsuccessful logins which would lock the user out within five or ten tries, but rather just repeated attempts that never finish, so a higher number is permitted. Others will forcefully slow down the ability of the person logging in to make another attempt after several tries, which could still allow this attack to happen but would make it cumbersome for the attacker. Of course, training users to avoid having their passwords stolen is also effective here, as the fewer valid credentials an attacker has, the fewer accounts they can try this with. 

MFA solutions – including AzureMFA – also have multiple methods to avoid using OTP’s entirely. The most popular current technique is to match a number or character on the screen with a number or character displayed in the authenticator app alongside other, wrong, numbers/characters. You may see a number like “81” on the screen, and have between three and nine numbers to choose from – only one of which is “81” – in the app. Tap the matching number, and you pass the MFA challenge. Additional options are tap-to-auth which just requires the user to tap a confirmation message on their phone (not recommended), and physical tokens such as the very popular Yubikey devices (solid and secure, but more cumbersome for users). 

This vulnerability is something organizations will need to guard against until Microsoft closes the ability to overwhelm the system with authentication requests, which they will probably do within a couple of days. If the organization is already using a matching system or physical token, and is not allowing the use of OTP’s, then there is less of a concern here. Restricting login attempts (not just failed logins)can also solve the problem if OTP’s are necessary for whatever reason. While it won’t eliminate the issue, enforcing longer and longer delays after each login attempt (successful or not) can also help to avoid the issue since the amount of time required to perform the attack will be longer than the attacker wants to wait. A real user will log in within a few attempts, and the initial delays are only a few seconds – but after a hundred attempts the attacker would have to wait minutes, and after a thousand they’d have to wait hours. An extremely determined threat actor might deal with that, but any others would give up quickly.

In short, there are options here that are not only available with AzureMFA, but can even make things easier on end users. Matching systems only require a tap, and are therefore easier for most users than copying six digits from one device to another. Though this is a concerning development in MFA security, its impact will be temporary (Microsoft will create a fix), will not require the organization to do anything on their end of things, and can be avoided entirely by restricting OTP use in favor of other – usually better – options. 

 

On Monday, a series of headlines popped up screaming that Amazon employee data was stolen. While there was data “stolen,” these headlines are the worst kind of click-bait, and we’re going to need to dive a bit deeper into the stories (like this one from TechCrunch) to spell out what happened, and why it is nowhere near as bad as those headlines sound.

First, what happened. Sometime in the last week or so, a third-party building contractor that Amazon works with had its systems compromised by a threat actor. The attacker used the moveIT vulnerability that made the news last year to intercept files which were being transferred back and forth between the contractor and many of their customers. Included in that set of files were – apparently – some files detailing Amazon employees who worked at facilities managed by the contractor. All of this appears to be true as of Monday evening, and I’m not seeing any reason to doubt the authenticity of the attack itself. 

Now, why this is becoming click-bait… 

While many websites are screaming that Amazon employee data was stolen – and while that is technically true – it wasn’t Amazon who got compromised and the data that was stolen was already public information anyone could get. Based on reports coming in, what was “stolen” from Amazon was a list of employees who worked in the various buildings managed by the contractors, the desk phone numbers of those employees, other non-sensitive contact information (like their email addresses), and – of course – what buildings they work in. All of this information can be obtained quickly and effectively by looking at social media, publicly available website info, or a whole host of other places. It’s already public, and didn’t need to be stolen at all, and is mostly useless to the threat actor except for embarrassing the facilities management firm. Amazon certainly has no reason to pay a ransom or do… well… anything.

So, yes, Amazon employee data was accessed without authorization. That data included general contact information and other details. All of this data could be acquired through dozens of other methods that are in no way threat activity because they revolve around just accessing publicly available websites and feeds. 

Always take the headlines with a grain of salt – read the whole article to find out what really happened. While outright hyperbole on this scale is rare (usually the attack is worse than the headline makes it out to be), it does still happen. To their credit, each of the actual stories I read that used one of these really outrageous headlines did detail what happened, but nearly none noted that the data was basically already visible to anyone who wanted to see it.  

Hang in there, and remember to always question what you’re reading when a headline is screaming at you.

As it is Cybersecurity Awareness Month, I’d like to post a perennial favorite of readers: My tips on how to spot a phishing email, text message, or call. 

While there is no guaranteed way to always be 100% sure that a message is real or fake (and therefore you should reach out to whoever sent the message to find out), there are things that the majority of phishing/smsish/vishing scams and attacks do hold in common. The reason is simple, threat actors realize they have to make their attack messages seem real, urgent, and mandatory for you to follow their instructions. Because of that, you should always be on the lookout for three “calls,” and when you see them you should immediately become much more suspicious of the message.

1 – A Call to Authority

Threat actors know that people will typically show doubt in any unexpected email asking them to do something. Most people even doubt text messages and phone calls these days. In order to overcome this, threat actors will attempt to impersonate a person, company, or government organization you are less likely to question. Common examples are known executives at the company you work for, companies you do business with like Microsoft and Amazon, or government agencies you have to interact with like the Internal Revenue Service here in the USA. By making a call to authority, threat actors have a better chance that you will act on the information in the message without questioning it. This typically takes the form of the email or text appearing to be coming from the person or company in question – either by spoofing a known email address, or just flat out stating they’re from the company or org in question in a text message or phone call. 

2 – Call to Urgency

We humans have a few common behaviors that threat actors like to take advantage of. One of those is that, when faced with an urgent situation, we tend to examine what is going on less often and act immediately more often. Because of this, threat actors will often try to imbue a sense of urgency into their messages to try to trick a person into performing an action as a kind of knee-jerk reaction; and not take time to question what is going on. Common examples of this are when you see messages saying your membership to an online service is locked/cancelled, or an invoice for a service must be paid immediately to avoid it going into collections. Other examples may be someone impersonating your boss demanding that you perform some action – like buying gift cards – that must be done right this minute since they’re in a critical meeting. All of these situations play upon our human nature and tendency to act quickly when we feel we’re in a significantly urgent situation. 

3 – Call to Specific Action

Nearly every message you get on your phone or via email has some kind of call to action. Your spouse reminding you to pick up bananas. Your boss telling you to complete a task. Your friends asking you to choose a restaurant to meet up at. What these examples have in common with normal and legitimate requests is that they have multiple paths that can be taken to complete them. You could step out at lunch to get bananas, or get them on the way home. You can complete the task yourself, or coordinate with your co-workers. You have a selection of restaurants to choose from, or can even suggest that someone else choose this time. While there are legitimate situations where only one path of action is possible, there are far more situations where there are multiple paths that can be taken. A message that is demanding that you take a very specific path of action should raise your suspicion levels significantly. Common examples of this are when you are required to use a specific link in the email to respond, or when you are given a specific phone number for a law enforcement agency in a voicemail that you must call. 

When you encounter one of these three calls by itself, there’s a good chance the message is legitimate. Your boss may call you, for example. When you see them stacking up together in a message, it is insanely likely that the message is some form of social engineering. When Apple emails you and demands you immediately call a specific phone number because your account is suspended, this is not a real email from Apple. When your boss texts you to demand you drop everything you’re doing and go buy a specific number of visa gift cards right this second, that is not a real text from your boss. When you get a phone call from the IRS demanding you immediately wire them funds via a named wire service to cover penalties or risk being arrested, that is not a legitimate call from the IRS. 

In each of those cases, there is a call to authority (Apple, your boss, the IRS), there is a call to urgency (this must be done RIGHT NOW!), and a call to a specific action (call a defined phone number, buy specific gift cards, wire money through a specific method). By looking for all three of these calls whenever you get a text, email, or phone call that you can’t confirm the origin of; you can quickly determine the likelihood that this is a scam, phish, or fake. Note that this doesn’t remove the need to use good online hygiene – you still shouldn’t click on a link or open an attachment unless/until you know who sent it and why – but by taking a step back and really looking closely whenever you see all three calls you can spot the fakes quickly and accurately. 

So how do you take the next step when you suspect a message may be fake, fraudulent, or phishing? 

1 – Calm Down: No matter how urgent the message may seem, legitimate requests nearly always give you at least a few minutes to figure things out. The sender of that message may not want you to, but you can, and you definitely should. Take a moment to review what is going on before you take action on it.

2 – Confirm: No matter who is reaching out to you, there are other paths you can use to confirm what is happening and if it is legitimate. For companies like Apple, Amazon, Microsoft, Netflix, your bank, etc.; you can independently visit the website in question via a browser (without clicking on links in the email or text), log in, and see if there are any messages or alerts waiting for you. If the Sheriff’s Office is calling you, then you can hang up, find a known and trusted number for them through a web search, and call them directly. If your boss needs something, you can take a moment to check with HR, or call your boss directly via a phone number you know to be assigned to them. Taking a minute or so to confirm what is going on can keep you from taking an action that you’ll regret later.

3 – Continue: After you take a moment to review the situation and then confirm the details via some other method of action than the email/text/phone call is demanding; you can then decide what to do next. If you can confirm that the request/demand is actually real, you can act on that. If you can’t confirm it – or if you’re able to confirm the demand is fake – you can report it and/or ignore it. If it has anything to do with your company, you should definitely report it. If it has to do with some other company or government organization, you should still report it via the methods on their corresponding websites, but that’s up to you. Reporting the incident helps everyone else stay safer by allowing companies, your organization, and other organizations better train their users to spot these fakes in future, and to involve law enforcement when necessary.

So remember, any time you see all three calls – A Call to Authority, A Call to Urgency, and A Call to Specific Action – in one message, then Calm Down, Confirm, and then – and only then – Continue. Stay safe out there.

Editors Note: This is a developing story, and little is known about the facts surrounding the events except that they happened. The article will be updated when more information is published (if that happens). Please remember that, as with any rapidly developing story, the truth of these events may not be known for quite some time. The editor would also like to thank @SchizoDuckie and @UK_Daniel_Card for their rational and technical support in keeping the author from getting derailed and wandering into spy thriller territory.

Update: October 16, 2024 – Reuters has posted a story detailing the results of an investigation around the pager devices.  This story contains details received from unnamed sources which highlight how the devices were given an online backstory, and – while not being able to discover exactly where they were manufactured – does detail what that manufacture looked like structurally.  This post has also been updated with some date corrections. 

Update: September 18  2024 – Multiple news outlets including NPR and CNN are citing a US Official in stating that Israel has claimed responsibility for the pager explosions. 

Update 2: September 18, 2004 – Both the Tiwanese first-party manufacturer and holder of the trademark branding for the pagers and the Hungarian 3rd-party manufucaturing company that licensed that trademark are denying that they manufactured or sold the pagers to Hezbolla. We may have to wait a significant amount of time for investigations to sort out the truth of where these devices came from.

Update 3: September 18, 2024 – An additonal wave of explosions, this time involving two-way radio devices and (possibly) solar devices has occured in Lebanon.  While no one has claimed responsibility yet, it stands to reason that this was a second-strike by the same group that detonated the pagers yesterday, presumably Israel.

Update 4: September 18, 2024 – The Guardian (a UK-based News Agency) has posted a story with more detail on how this may have happened. 

Original Post:

It would seem that there are quite a few things happening these last few months that create an immediate need for an explanation in plain english. Today has continued the trend, as I got bombarded by people asking “What happened in Lebanon with the exploding pagers?” Let’s dive into this topic, and hopefully I can offer some reassurance that a world-wide panic is not needed at this time.

Please note, while I have had training in some forms of chemistry in college, I am NOT an explosives or demolitions expert. The details I provide here were gleaned from hastily-performed research on the subject. This is also a longer article than usual, because the topic is complex and full of twists and turns; so breaking it down into plain english is going to require a lot of words.

TL;DR version: No, your phone is not going to explode unless there was a defect in manufacturing, and even those are rare. What happened was not a cyber attack, but rather an act of war that included a digital transmission component. The devices were built to *be* bombs, not converted into bombs by some kind of software magic. Read on for details.

First, some background. On September 17th, thousands of pagers (those old-school devices that let someone send you a phone number or short text string to let you know to call them back) detonated in dozens of locations throughout Lebanon. All of the pagers (as of this moment) were being carried by members of the group Hezbollah, an extremist group which has carried out numerous terrorist plots and attacks over the last several decades. This link to the New York Times coverage of the event is paywalled for many, but one of the better sources of news and information on this particular situation: https://www.nytimes.com/live/2024/09/17/world/israel-hamas-war-news

While no one has yet declared responsibility for the attack, it is likely that this action was carried out by Israel as part of their ongoing conflict in the region. This is one of many points of fact that are not confirmed yet, so it is only a suspicion at this time. Considering the last operation of this scale that Israel was involved in (Stuxnet) went un-declared for 30 years, we may not know for a very long time at that. 

This leads to the inevitable question, “Can a pager (or any other mobile device) that I’m wearing or carrying become a bomb?”

The answer is a bit complex, but the short form is “not unless there was a defect in manufacturing,” and also that it is highly unlikely that today’s events were anywhere near that straight-forward. Rather, it is much more likely the exact opposite – that bombs were fashioned into mobile devices instead of mobile devices being turned into bombs themselves. Let me walk you through that.

The definition of a bomb is simply a massive amount of energy (usually in the form of heat and/or pressure) suddenly being created but trapped inside of an enclosed space. Eventually the heat and pressure exceed the ability of whatever space is containing it, and the result is a rapid dispersal of the heat, pressure, and whatever the container was made of into the immediate surrounding environment; i.e. it explodes. In this case, something caused the pagers – made of plastic with circuit boards, a battery, a small screen, and a few other components – to become the container for all the energy. When the container couldn’t hold back the energy anymore, it exploded; seriously injuring anyone nearby – including whoever was wearing the pager or had it in their pocket at the time.   

Such an explosion could be caused by many different substances. We’ve seen lithium-ion batteries explode before – https://www.cnn.com/2023/03/09/tech/lithium-ion-battery-fires/index.html – but they generally convert themselves to heat more slowly, causing very hot fires but not what we saw in the videos coming out of Lebanon today. On the other side of the equation, there are many compounds that do not take a large amount of space or weight to create significant explosions. I won’t list them out here, but a quick google search will bring them up if you don’t mind that info being in your browser history.

It is also critical to point out that these were not pagers that you could buy from a local electronics store. These were encrypted devices designed to facilitate communications between members of a known terrorist organization (using the US and UK designation for Hezbollah). Therefore, they had to either have been built for that purpose, or heavily modified to suit that purpose. This becomes vitally important later in this article. 

So, what do we know as of this moment? Two things. First, that specialized pager devices which were being worn and/or carried by thousands of Hezbollah members exploded nearly simultaneously throughout Lebanon. Second, that it is unlikely to have been caused by the batteries or internal electronics of the devices themselves due to the explosions being very different from a standard lithium-ion battery fire. 

That can lead us to a set of conclusions, but this is pending additional information which may – or may not – come out later:

It is likely that an external group – potentially the Israeli security organization Mossad – managed to replace the pagers the Hezbollah members were expecting to get with devices that had been altered to include an explosive charge and a detonation system. Alternately, as noted by Reddit user UrsusArctus – https://www.reddit.com/user/UrsusArctus/ – the pagers may have been built with the capability to be remotely destroyed if they were to be lost or stolen as a Hezbollah security measure. This last scenario is less likely because Hezbollah has not been well-known to maintain such a level of Operational Security (OpSec), but it is possible and should be considered. 

This leaves us with pagers that contain an explosive charge on purpose (put there by either an external group or by Hezbollah themselves), and some way to trigger that charge to go off on-command. In scenario one, whoever diverted and altered the pagers would have built in the ability to trigger the explosion by sending a specific code to the device or through some other remote activation. In the scenario where the devices already had a self-destruct function, a security agency (i.e. spy group) could have found the sequence of codes or other operations which would trigger such a function. On-command, all of the pagers received the code to detonate, and the result is what we saw today.

What does this mean to everyone who is not a Hezbollah agent carrying a pager? Can this be done to a regular mobile phone? A laptop? My doorbell?! – in short, it’s insanely unlikely unless you’re being targeted by a state-sponsored espionage agency, and even then there is very little chance. In cybersecurity, we don’t like using terms like “never,” but this is as close to never as you’re going to get.  

The level of coordination and secrecy necessary to pull off either of the two scenarios (replacing the pagers or infiltrating the self-destruct system) is so massive that we almost never see anyone pull off this kind of attack. It has happened for espionage purposes – see https://www.securityweek.com/chinese-gov-hackers-caught-hiding-in-cisco-router-firmware/ – but it is just absolutely rare as to be close to non-existent, and certainly insanely rare for acts of war like we saw today. While it is true that Mossad has rigged exploding mobile phones in the past, each incident was one phone, given to one target by a spy or through some other means – never anything at this massive of a scale. 

Remember that in the first scenario, you must have infiltrated and compromised the supply chain for the devices – a supply chain that routinely deals with a terrorist organization who is likely to retaliate with extreme prejudice. This would require that you basically control everything about the supply chain to an extent that no one who is part of the manufacturer or the other suppliers knows you are there, because they will certainly call you out to the bad guys if they figure out you are there.

In the second case, you would have to have had operatives in place within the terrorist group itself long enough for them to acquire access to the self-destruct systems. This is much more possible with really good spies, but still not something that your average threat actor could pull off with any level of success. Also of note, your devices would have to be rigged to explode in the first place, which I can safely assume no one reading this article has built into their iPhone. 

In both cases, it would only be possible to carry out this kind of attack because the devices were specifically built for use by the group that was targeted. These devices worked on an encrypted network, and therefore would have to be purpose-built or modified to function on that network. This allowed whoever carried out the attack to specifically target hardware and users to an incredibly precise degree. Trying to do this with commodity devices like Android phones would make it impossible to ensure that you attack those people you’re looking to attack, and them alone. Using off-the-shelf commercial devices like this also means there is a significantly higher – almost guaranteed – chance that the alterations are discovered before you can put your plan into action. So it isn’t the kind of thing that you’d see being done unless it was directly, highly, and explicitly targeted.

This is also something that can only be done once. That’s it. Now, everyone who uses covert mobile devices is going to be looking to make sure that they haven’t been tampered with; and those with self-destruct systems will disable them until they can re-secure the control systems. 

Finally, there’s no profit in this. Remember that cyber threat actors are typically in this to make money through extortion and/or resale of the data they steal. Blowing up someone’s phone doesn’t aid that goal in any way, since the device and its data are now gone. Not to mention the massive law-enforcement reaction because you either could have or actually did injure and possibly kill people. Even for hacktivists, detonation of a target will not gain them any ground, and will probably cause them to lose quite a lot instead. 

Taken together, this indicates that the attack was a state-motivated and state-sponsored act of war, and not a cybersecurity incident. Technically, it involved a cyber aspect – the devices were remotely detonated through some form of digital connectivity – but would not be classified as a cyber attack itself. This is not something that you are going to see happening frequently, and certainly not something that we’re likely to see be used as part of a cyber attack in the traditional sense. It’s also extremely unlikely that the devices were turned into bombs with just the components that would normally be part of the pager/phone/whatever. Either the devices were substituted for ones that contained an explosive charge, or the devices were built to have a self-destruct feature; they were built to be bombs, they didn’t become bombs through some technological trickery. 

So, for 99% of us, there is no real likelihood that our phones will explode without warning. Or, at least no more of a likelihood than already exists due to accidental manufacturing issues – https://www.wired.com/2017/01/why-the-samsung-galaxy-note-7-kept-exploding/ . Instead, we should maintain focus on actual cyber threats. It is far more likely that you will fall victim to a phishing or text scam, accidentally download and run malware, or do a hundred other things that do not involve explosions at all, but still cause significant damage to your personal digital systems and/or company.

Because of the recent news  that 2.9 billion (with a B) Social Security Numbers for US Citizens had been stolen from a background investigation firm, lots of people have been asking me to talk about what they should do.  

 

The short answer is… nothing. 

 

While this latest massive data breach is concerning to be sure, the fact that billions of Social Security Numbers were stolen is not the story. Unfortunately for all of us in the US (or who otherwise have a US Social Security Number), that data is almost definitely already known to the general public and the threat actor community. So, let’s look a little deeper about why you don’t need to be all that worried that your Social Security Number ended up in a huge data dump, again.

First, a bit about Social Security Numbers (SSNs). For those outside the USA, SSNs are numbers used to identify each US citizen in order to track a government-managed welfare program system called – you guessed it – Social Security. It’s managed by the Social Security Administration  and provides multiple services for citizens during their lifetime. SSNs are usually assigned shortly after a person is born, or shortly after they become a citizen if they immigrated. They are issued once and, with only a few incredibly rare exceptions, they are never changed during a person’s lifetime. So for most of us living here in the USA, we have one that was assigned to us at birth and will be with us until after we die. 

While these numbers were never meant to be used as any form of identification, they ended up being used for exactly that purpose over the 80+ years the system has been in active country-wide use. SSNs are used on tax forms, medical records, employment records, financial records, and just about everything else. The issue is that there are zero security controls around these numbers. While organizations who collect them are required to use reasonable and standard practices to protect the data; the actual number is not randomized or anonymized in any way by anyone – including the agency that issues it to you. 

The numbers themselves can be decoded and even guessed if you have enough information on a person. Entire calculators and decoders exist, because the SSN was meant to be decoded so it could be used to route benefits properly – such as this site. Because of this, SSNs should never be considered privileged or private information – they’re just too easy to figure out.

Additionally, as with any program that’s been in existence for nearly a century now, just about any organization or agency that’s held SSNs has lost control of some or all of that data over the years. So many data breaches (both physical paper-based access and digital access) have included SSNs that – at this point – you’d be in a ultra-tiny minority if your SSN wasn’t already known to anyone who wanted to find it. 

So, what to do about this breach? As I said at the top, there’s really not much to do in this case, nor is there much to worry about. The breach did include much more sensitive information that – when present all together in one place – absolutely could lead to identity fraud and other nefarious activity. Your SSN being the data dump, on the other hand, really isn’t a big deal. Keep an eye on your credit score/reports, be very wary of emails, text messages, or phone calls that want you to buy something or pay money or share additional information. Always remember that the FBI, Apple, Microsoft, Google, the Sheriff’s Office, etc. won’t call you first. When in doubt, ignore the link in the email and/or hang up the phone; then manually go to the website in question and log in or find a number to call to ask about the situation. Trust me, if any government organization or corporation needs you to do something, there will be a web page on their site or a phone number where they can tell you what they want you to do. None of them work exclusively by outbound email or phone calls. 

Threat activity generated from data breaches is very real. Follow good online hygiene and be cautious with any phone calls or texts – but you should be doing that even when you aren’t hearing about a massive data leak these days. The fact that SSNs were in the latest breach doesn’t change anything, and should be the issue you’re least concerned about surrounding this ongoing problem. 

It’s probably known to just about everyone in the world right now that on Friday, July 19 2024, millions of computers went offline unexpectedly due to the software provided by CrowdStrike – a vendor specializing in cybersecurity tools. Many have asked for an explanation at a high level as to what happened an why, so let’s dive into this topic. Settle in, this is going to be a long one. 

Editor’s Note for Disclosure: While the author works for an organization which offers sales and services around CrowdStrike products, they also offer such sales and services for a wide variety of other EDR/XDR solutions. As such, objectivity can be preserved.

First, some background information:

 

CrowdStrike is a well-known and well-respected vendor in the cybersecurity space. They offer a large range of products and services to help businesses with everything from anti-malware defenses to forensic investigations after a cyber attack occurs. For the most part, their software works exceptionally well and their customers are typically happy with them as a company. 

Endpoint Detection and Response (EDR) is the general term for any software that looks both for known malware files on a computer and also looks at what things are actively running on a computer to attempt to determine if they may be some form of yet-unknown malware. These operations are often referred to as “signature/heuristic scanning” and “behavioral detection” respectively. While it isn’t necessary to understand the ins and outs of how this stuff works to understand what happened on Friday, CrowdStrike has a product line (Falcon XDR) which does both signature scanning and behavioral detection. 

EDR solutions have two forms of updates that they regularly get delivered and installed. The first type is one most of us are familiar with, application updates. This is when a vendor needs to update the EDR software itself, much like how Windows receives patches and updates. In the case of an application update, it is the software itself being updated to a new version. These updates are infrequent, and only released when required to correct a software issue or deploy a new feature-set. 

 

The second form of update is policy or definition updates (vendors use different terms for these, we will use “definition updates” for this article). Unlike application updates, definition updates do not change how the software works – they only change what the EDR knows to look for. As an example, every day there are new malicious files discovered in the world. So every day, EDR vendors prepare and send new definitions to allow their EDR to recognize and block these new threats. Definition updates happen multiple times per day for most vendors as new threat forms are discovered, analyzed, and quantified. 

The other term that was heard a lot this weekend was “kernel mode.” This can be a bit complex, but it helps if you visualize your operating system (Windows, MacOS, Linux, etc.) as a physical brick-and-mortar retail store. Most of what the store does happens in the front – customers buy things, clerks stock items, cash is received, credit cards are processed for payment. There are some things, like the counting of cash and the receiving of new stock, that are done in the back office because they are sensitive enough that extra control has to be enforced on them. In a computer operating system, user space is the front of the store where the majority of things get done. Kernel space is the back office, where only restricted and sensitive operations occur. By their nature, EDR solutions run some processes in the kernel space; since they require the ability to view, analyze, and control other software. While this allows an EDR to do what it does, it also means that errors or issues that would not create major problems if they were running in user space can create truly massive problems as they are actually running in kernel space. 

OK, with all that taken care of… what happened on Friday?

Early in the morning (UST), CrowdStrike pushed a definition update to all devices running their software on Windows operating systems. This is a process that happens many times a day, every day, and would not normally produce any kind of problems. After all, the definition update isn’t changing how the software works or anything like that. This update, however, had a flaw which set the stage for an absolute disaster. 

Normally, any changes to software in an enterprise environment (like airlines, banks, etc.) would go through a process called a “staged rollout” – the update is tested in a computer lab, then rolled out to low-impact systems that won’t disrupt business if something goes wrong. Then, and only then, it goes out to all the other systems once the company is sure that it won’t cause trouble. For CrowdStrike application updates, this process happens like any other software update, and they are put through a staged rollout process. However, definition updates are not application updates, and because of both the frequency of definition updates and the nature of their data (supplying new detection methods), they are not subject to staged rollout by the customer. In fact, customers rarely have even the ability to subject definition updates to staged rollouts themselves – the feature just doesn’t exist in nearly all EDR platforms. There are several EDR vendors who do staged rollouts to their customers, but once a definition update is pushed, it is installed immediately for every customer in that phase of the rollout. CrowdStrike pushed this update out to over 8 million systems in a matter of minutes.

This particular definition update had a massive issue. The update itself was improperly coded, which made it attempt to read an area of memory that couldn’t exist. In user space, this problem would just cause the application to crash, but not have any other impact on the system. In kernel space, however, an error of this type can cause the system itself to crash, since in kernel space the “application” is – essentially – the operating system itself. This meant that every machine which attempted to apply the definition update (over 8.5 million at last count) crashed immediately.

To recover from this issue, a machine would need to be booted into Safe Mode – a special function of Windows operating systems that boots up the machine with the absolute bare minimum of stuff running. No 3rd-party applications, no non-essential Windows applications and features, etc. Once booted into Safe Mode, the offending update file could be deleted and the machine rebooted to return to normal. 

So, why did it take days to make this happen if you just had to reboot into Safe Mode and delete a file? Well, there are two reasons this was a problem:

First, Safe Mode booting has to be done manually. On every single impacted device. When we may be talking about tens of thousands of devices in some companies, just the manpower needed to manually perform this process on every single machine is staggering. 

Second, if the machine is using BitLocker (Microsoft’s disk encryption technology) – which they all absolutely should be using, and the majority were using – then a series of steps must be performed to unlock the disk that holds the Windows operating system before you can boot into Safe Mode and fix the problem. This series of steps is also very manual and time consuming, though in the days following the initial incident there were some methods discovered that could make it faster. Again, when applied against tens of thousands of devices, this will take a massive amount of people and time. 

Combined, the requirement to manually boot into Safe Mode after performing the steps to unlock the drive led to company IT teams spending 72 hours and longer un-doing this bad definition update across their organizations. All the while, critical systems which are required to run the business and service customers were offline entirely. That led to the situation we saw this weekend, with airlines, stores, banks, and lots of other businesses being unable to do anything but move through the recovery process as quickly as they could – but it was still taking a long time to accomplish. Of course this led to cancelled flights, no access to government and business services, slow-downs or worse in healthcare organizations, etc. These operations slowly started coming back online over the weekend, with more still being fixed as I write this on Monday.

Now that we’ve got a good handle on what went wrong, let’s answer some other common questions:

“Was this a cyber attack?” No. This was a cyber incident, but does not show any evidence that it was an attack. Incidents are anything that causes an impact to a person or business, and this definitely qualifies. Attacks are purposeful, malicious actions against a person or business, and this doesn’t qualify as that. While the potential that this was threat activity can not yet be entirely ruled out, there are no indications that any threat actor was part of this situation. No group claimed responsibility, no ransom was demanded, no data was stolen. The incident also was not targeted, systems that were impacted were just online when the bad update was available, and therefore it was pretty random. This view may change in future as more details become available, but as of today this does not appear to be an attack. 

“Why did CrowdStrike push out an update on a Friday, when there would be less people available to fix it?” The short answer is that definition updates are pushed several times a day, every day. This wasn’t something that was purposely pushed on on Friday specifically, it was just bad luck that the first update for Friday AM had the error in it. 

“How did CrowdStrike not know this would happen? Didn’t they test the update?” We don’t know just yet. While we now know what happened, we do not yet have all the details on how it happened. It would be expected that such information will be disclosed or otherwise come to light in the coming weeks. 

“Why was only Windows impacted?” Definition updates for Windows, MacOS, and Linux are created, managed, and delivered through different channels. That is something that is common for most EDR vendors. This update was only for Windows, so only Windows systems were impacted.

“Was this a Microsoft issue?” Yes and no, but in every important way no. It was not actually Microsoft’s error, but since it only impacted Windows systems it was a Microsoft problem. Microsoft was not responsible for causing the problem, or responsible for fixing it, though they did offer whatever support and tools they could to help, and continue to do so. 

“Couldn’t companies test the update before it rolled out?” No, not in this case. The ability to stage the rollout of definition updates is not generally available in EDR solutions (CrowdStrike or other vendors) – though after this weekend, that might be changing. There are very real reasons why such features aren’t available, but with the issues we just went through, it might be time to change that policy. 

“How can we stop this from ever happening again?” The good news is that many EDR vendors stage the rollout of definition updates across their customers. So while a customer cannot stage the rollouts themselves, at least only a limited number of customers will be impacted by a bad update. No doubt CrowdStrike will be implementing this policy in the very near future. The nature and urgency of definition updates makes traditional staging methods unusable as organizations cannot delay updates for weeks as they do with Windows updates and other application updates. That being said, some method of automated staging of definition updates to specific groups of machines – while truly not optimal – might be necessary in future.

To sum up, CrowdStrike put out a definition update with an error in it, and because this definition update was loaded into a kernel-mode process, it crashed Windows. Over 8.5 million such Windows machines downloaded and applied the update before the error was discovered, causing thousands of businesses to be unable to operate until the situation was corrected. That correction required manual and time-consuming operations to be performed machine by machine, so the process took (and continues to take) a significant amount of time. No data theft or destruction occurred (beyond what would normally happen during a Windows crash), no ransom demanded, no responsibility beyond CrowdStrike claimed. As such, it is highly unlikely that this was any form of cyber attack; but it was definitely a cyber incident since a huge chunk of the business world went offline. 

Editor’s Note: This is an emergent story, and as such there may be more information available after the date of publication. 

Many readers have been asking: “What happened with Snowflake, and why is it making the news?” Let’s dive into this situation, as it is a little more complex than many other large-scale attacks we’ve seen recently.

Snowflake is a data management and analytics service provider. What that essentially means is that when companies need to store, manage, and perform intelligence operations on massive amounts of data; Snowflake is one of the larger vendors that has services that allow that to happen. According to SoCRadar [[ https://socradar.io/overview-of-the-snowflake-breach/ ]], in late-May of 2024 Snowflake acknowledged that unusual activity had been observed across their platform since mid-April. While the activity indicated that something wasn’t right, the investigation didn’t find any threat activity being run against Snowflake’s systems directly. This was a bit of a confusing period, as usually you would see evidence that the vendor’s own systems were being attacked when you had strange activity going on across the vendor’s networks. 

Around the time of that disclosure, Santander Bank and Ticketmaster both reported that their data had been stolen, and was being held ransom by a threat actor. These are two enormous companies, and both reporting data breach activity within days of each other is an event that doesn’t happen often. Sure enough, when both companies investigated independently, they both came to the same conclusion – their data in Snowflake was what had been stolen. Many additional disclosures by both victim companies and the threat actors themselves – a group identified as UNC5537 by Mandiant [[ https://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortion ]] occurred over the following weeks. Most recently, AT&T disclosed that they had suffered a massive breach of their data, with over 7 million customers impacted [[ https://about.att.com/story/2024/addressing-data-set-released-on-dark-web.html ]].

So, was Snowflake compromised? Not exactly. What happened her was that Snowflake did not require that customers use Multi-Factor Authentication (MFA) for users logging into the Snowflake platform. This allowed attackers who were able to successfully get malware on user desktops/devices to grab credentials; and then use those credentials to access and steal that customer’s data in Snowflake. This was primarily done by tricking a user into installing/running an “infostealer” malware, which allowed the attacker to see keystrokes, grab saved credentials, snoop on connections, etc. All the attacker needed to do was infect one machine that was being used by an authorized Snowflake user, and they could then get access to all the data that customer stored in Snowflake. Techniques like the use of password vaults (so there would be no keystrokes to spy on) and the use of MFA (which would require the user acknowledge a push alert or get a code on a different device) would be good defenses against this kind of attack, but Snowflake didn’t require these techniques to be in use for their customers.

Snowflake did not – at least technically – do anything wrong. They allow customers to use MFA and other login/credential security with their service, they just didn’t mandate it. They also did not have a quick way to turn on the requirement for MFA throughout a customer organization if that customer hadn’t started out making it mandatory for all Snowflake accounts they created. This is a point of contention with the cybersecurity community, but even though it is a violation of best practices it is not something that Snowflake purposely did incorrectly. Because of this, the attacks being seen are not the direct fault of Snowflake, but rather a result of Snowflake not forcing customers to use available security measures. Keep in mind that Snowflake has been around for some time now. When they first started, MFA was not an industry standard and customers starting to work with Snowflake back then were unlikely to have enabled it. 

Snowflake themselves have taken steps to address the issue. Most notably, they implemented a setting in their customer administration panel that lets an organization force the use of MFA for everyone in that company. If any users were not set up for MFA, they would need to configure it the next time they logged in. This is a good step in the right direction, but Snowflake did make a few significant errors in the way they handled the situation overall:

 – Snowflake did not enforce cybersecurity best practices by default, even for new customers. While they have been around long enough that their earlier customers may have started using the service before MFA was a standard security control, not getting those legacy customers to enable MFA was definitely a mistake. 

 – They also immediately tried to shift blame to customers who had suffered breaches. The customers in question were responsible for not implementing MFA and/or other security controls to safeguard their data; but attempting to blame the victim rarely works out in an vendor’s favor. In this case, the backlash from the security community was immediate and vocal. Especially when it came to light that there was no easy way to enable MFA across an entire customer, they lost the high ground quickly. 

 – That brings us to the next issue Snowflake faced: they didn’t make it easy to enable MFA. Most vendors these days allow for a quick way to enforce MFA across all users at that customer; with many vendors now having it be opt-out; meaning customer users will have to use MFA unless the customer organization opts-out of that feature. MFA was opt-in for Snowflake customers, even those signing up more recently when the use of MFA was considered a best practice by the cybersecurity community at large. With no quick switch or toggle to change that, many customers found themselves scrambling to identify each user of Snowflake within their organization and turn MFA on for each, one by one. 

Snowflake, in the end, was not responsible for the breaches multiple customers fell victim to. While that is true; their handling of the situation, attempt to blame the victims loudly and immediately, and lack of a critical feature set (to enforce MFA customer-wide) has created a situation where they are seen as at-fault, even when they’re not. A great case-study for other service providers who may want to plan for potential negative press events before they end up having to deal with them. 

If you are a Snowflake customer, you should immediately locate and then enable the switch to enforce MFA on all user accounts. Your users can utilize either Microsoft or Google Authenticator apps, or whatever Single Sign-On/IAM systems your organization uses. 

A reader contributed a great question recently: “So many more ransomware attacks are getting talked about in the news. Is ransomware growing that quickly, or does it just seem worse than it is?” The answer is “both,” but let’s break things down.

 

According to Security Magazine, ransomware has indeed grown exponentially in the last year, with an 81% increase in attack activity. That’s certainly not good, but may not be telling the whole story. While there’s no doubt that threat actors have increased attacks via Ransomware-as-a-Service (RaaS) and more sophisticated automation; some of what we’re seeing is an increase in the number of reported attacks compared to previous years.  

 

Better automation allows threat actors to perform more attack attempts in the same amount of time than they’d be able to perform manually. Scripting and automation have increased the effectiveness of legitimate organizations in many different ways. Processes like allowing a user access to an application which would have previously taken days or a week can now be done in seconds – safely. Stocks trades that would take hours in years past are now done in seconds – also safely, usually. As legitimate businesses have embraced automation to make their organizations better, threat actors have done the same. Now, a new exploit that would allow for a new attack, which would normally take weeks or months to see significant spread throughout the world, can become a major world-wide threat in hours. This, of course, means that more attack attempts leads to more successful attacks and higher numbers of organizations compromised year over year. 

 

RaaS allows established threat actor cartels to re-package and sell attack protocols they no longer use themselves to lower-tier threat actors. This extends the life of the product (the ransomware attack), and allows the cartel to continue to make money from it for much longer periods of time. By having more threat actors use existing tools against still-unpatched systems, more organizations end up compromised.

 

Both of these factors have lead to a marked increase in the total number of ransomware victim organizations over time, and that can’t be dismissed as a statistical blip or anything like that. We’re facing more attacks, more often, across more industries.

 

However, it should be noted that a huge portion of the compromised organizations would not – until recently – have reported the compromise at all. Businesses have many reasons to attempt to hide the fact that they fell victim to a ransomware attack. Loss of customer trust, violation of clauses in contracts, endangering future business – all reasons companies may choose to hide that an attack took place. This isn’t new behavior, as companies would often try to gloss over or bury anything that could impact their bottom line as you would expect – we’re just now talking about impacts caused by digital disasters instead of bad accounting practices, corporate espionage, and other more traditional events. 

 

Generally, if such hidden events and setbacks would cause overall market impact or jeopardize citizens of a country or locality; government agencies create regulation to make it mandatory to report it. This is not something that’s done frequently, and only occurs when the burying of such events would create major fallout in an entire market or a large group of citizens. Typically, new regulations only occur after such a major impact occurs. Over the last several years, the impact of cybersecurity incidents has indeed begun to cause fallout in markets, and has caused impact to massive amounts of citizens through identity theft and other problems. Because of this, governments have begun to pass legislation that makes it mandatory to quickly disclose any cybersecurity incident which might have a “material impact” to markets and/or consumers. You can read more about one such regulation in a previous post here.

 

In the USA, both the Federal Government (specifically the Securities and Exchange Commission) and several State Governments (most notably New York and California) have already passed regulations which compel organizations to report incidents via public filings. The SEC, for example, requires the filing of an amendment to a regular reporting form (8-K) within four days of any incident that has material impact, and the incident must also be part of the annual 10-K filing every public company and certain other companies must file. Since these reports are public, anyone and everyone can view them. Other US states either have regulations that are being/have been amended to cover cybersecurity incidents, or are creating new legislation to make disclosure mandatory for any companies that do business within that state or territory. The European Union and other nations/coalitions are also either strengthening reporting regulations or implementing new regulations specifically around cybersecurity incident reporting.

 

The practical upshot of this is that significantly more incidents are becoming public knowledge that would not have been publicly reported previously. Incidents that would have been “swept under the rug” in previous years are now becoming public knowledge quickly, leading to a marked uptick in the number of known attack victim organizations. While this number is certainly not enough to account for the total increase in attacks, it has most definitely increased the number of reported attacks over the last few years. The combination has lead to massive increases in year-over-year ransomware reports, leading to dramatic news reporting on the problem. As the issue becomes more sensational, everyone hears about it more often and with more volume.

 

So, while it is true that the total number of ransomware attacks has increased sharply due to a combination of the rise Ransomware-as-a-Service and the use of automation in threat actor activities, it is important to also realize some of the sensational numbers are attributable to companies being required to talk about the problem more than in the past. In total, the issue of ransomware and other cybercrime is taking a much bigger share of the public interest – which is a very good thing – but we must look at all of the factors that lead to such numbers to more fully understand what’s going on.