Victim notifications are exactly what they sound like—a notification that you have fallen victim to something. In the ever-changing world of cybersecurity, victim notifications happen more frequently as better detections and collaborations in the security industry lead to vulnerabilities either privately being disclosed to a product company or publicly being highlighted for the community.
Victim notifications can happen in several ways, but the following two methods are the most common:
- Law enforcement notification. Scenarios could include a law enforcement agency notifying a victim that there has been malicious traffic from their IP space to a known malicious actor’s owned infrastructure; or law enforcement has acted against a known threat actor and additional victims have been identified through analysis of the threat actors’ controller data.
- Security product company. This can happen when a product company applies new detections for emerging threats and notifies customers of the potential impact of ongoing or historic activity that the victim should investigate. Another way this can happen is that during routine hunting based on other threats, similar tradecraft has been identified and the product company is proactively notifying a new potential victim.
Security product companies have used victim notifications to provide some additional top coverage for their customers as new threats emerge. As law enforcement throughout the world combines forces to take on some of the most prolific ransomware actors, their work and collaboration will likely result in new victim notifications for related incidents that were interrupted as a result.
Being notified of an attack can be a very confusing time if the organization is not familiar with the process. Typical questions arise, including:
- Is this notification even real?
- How does the notifier know we are a true victim?
- What data can they provide to confirm that we’ve been victimized?
- Is there anything from the notification we can provide to our incident responders to verify?
Delivering victim notifications is something of an art form. There are no real rules or standards around how to disclose, but over the years some organizations have begun to standardize the process a bit more.
Some organizations will push the victim notification out through the product company’s sales representative. If a product company has a Managed Detection and Response (MDR) service, a representative from that team could be tasked with reaching out with some additional steps to help mitigate.
Are You Legit?
The delivery method and contents of the victim notification can help the organization ascertain if the notification is valid or not. If the notification is coming through proper channels from a valid email address, it should be taken seriously. (In fact, this is oftentimes a tabletop exercise played out during strategic security planning activities.)
Common ways to verify if a notification is legitimate include:
- Is the email/notification from a known sender, or an individual from a known organization?
- Does the email/notification contain information related to an actual vulnerability or security-related topic that can be freely searchable? That is, can you Google it without navigating to the links they provided?
- Did they provide any additional information such as indicators or a way to contact them for additional information?
Whenever receiving a non-solicited email, phishing should always be at the forefront of your mind, especially as a global security incident is underway. This is especially true if there is no dedicated email address for the information security team. However, a knowledgeable person working to disclose a victim notification should provide at least the following information to demonstrate credibility:
- Use their business email address
- Provide their background
- Provide a brief background on the situation
- Offer an option to set up a call to discuss in depth details, so that the right team members are available to address the potential problem
Once the victim notification has been delivered, it’s up to the victim organization to verify whether a potential incident impacted the organization—and if so, to what capacity. This can also cause some friction as the team determines what’s needed for an investigation.
- Does the victim organization have a retainer with a third-party incident response company?
- Does it have cyber-insurance to pay for the investigation?
- Does it retain legal counsel for this investigation?
Most importantly, does the organization know the proper timing to make these decisions? As the media spotlight has fallen on ransomware actors that operate in a ransomware-as-a-service or other various “affiliate” models, this is becoming increasingly important.
That’s because threat actors have varying levels of sophistication and speed. These speeds can range from two hours from initial compromise to weeks before the threat actor decides to deploy ransomware. These timelines depend heavily on the threat actor performing the attack and the security posture of the environment.
What Is the Endgame?
When discussing the victim notification with the organization that performed the disclosure, a key detail to understand is: “What is the typical end goal of the threat actor?” Sometimes these conversations will give information highlighting potential nation-state sponsors, commonly referred to as Advanced Persistent Threat (APT) groups.
Others may result in the notification of financially motivated groups like FIN7 or one of the many ransomware affiliate groups. Responding to these actors may require a different timeline based on the threat model of the victim.
Understanding the motivation behind the potential incident can help a security team understand the proper course of action to take when preparing to contain and eradicate a threat actor from the environment. Typically speaking, the threat of ransomware will spark the need for a more expedited containment and eradication effort than most other incidents.
Practice, Practice, Practice
The best way to prepare for anything—especially including ransomware incident response—is to practice. Build in quarterly, or as routinely as your team can accommodate, hands-on workshops that simulate the actual processes of handling a victim notification scenario. This should include, but not be limited to, working with your incident response team (in-house or third party) to understand the realistic time frames for requests.
Some typical areas that are hurdles for incident responders include:
- Data owners are not knowledgeable about what data is available. It’s crucial to know which teams own which data retention policy, which team determines what needs to be logged, and so on
- The time frame the victim organization can provide log data for
- Are the logs dating back to the incident available in a timely fashion (it can be important to know, for instance, how long it takes to unarchive historical logs)?
- Lack of decision maker(s) or incident commander to help direct the investigation
Responding to victim notifications can be a daunting task, but it’s a fact of life in the current age. Victim notifications are considered “external notifications,” which means that the clock has already been ticking for some time.
As with any incident, it’s important to understand the time frame in which the incident needs to be dealt with versus the time frame in which your organization can feasibly respond.
Adding this tabletop session in preparation for receiving a notification will help to narrow down the delta between the expected time frame for incident handling and the current operating capacity of your team.
This kind of preparation, coupled with practicing other topics related to responding to an event like a threat actor keen on deploying ransomware within your environment, will enable your team to be more prepared than the bad guys.