Responding to a ransomware attack requires a well-defined and organized approach to effectively mitigate the threat, minimize damage, and restore systems. Here’s a checklist for a Security Operations Center (SOC) during a ransomware attack:
Preparation Phase:
Incident Response Plan (IRP): Ensure your SOC has a well-documented and up-to-date incident response plan that includes specific steps for handling ransomware incidents.
Team Activation: Initiate the incident response team, including representatives from IT, security, legal, communications, and management.
Isolation: Isolate affected systems from the network to prevent further lateral movement and propagation of the ransomware.
Secure Communication Channels: Establish secure communication channels for internal and external communication, considering potential compromise of regular communication channels.
Identification and Analysis Phase:
Confirm Ransomware: Determine if it’s indeed a ransomware attack by analyzing the ransom note, encrypted files, and other indicators.
Collect Evidence: Gather information such as log files, network traffic captures, system snapshots, and any ransomware-related artifacts for analysis.
Ransomware Variant Identification: Identify the specific ransomware variant, if possible, to understand its behavior and potential decryption options.
Scope Assessment: Determine the extent of the infection and affected systems, including critical assets and data.
Containment Phase:
Isolation: Continue isolating affected systems to prevent the spread of the ransomware. Disconnect infected systems from the network.
Implement Firewall Rules: Update firewall rules to block any malicious network traffic associated with the ransomware.
Endpoint Security Measures: Apply security patches, updates, and configurations to the affected systems to prevent further exploitation.
Eradication Phase:
Malware Removal: Use updated antivirus and anti-malware tools to remove the ransomware from affected systems.
Root Cause Analysis: Determine how the ransomware entered the network and identify vulnerabilities that were exploited. Patch and secure these vulnerabilities.
Recovery Phase:
Data Restoration: Restore systems from clean backups, ensuring that backup data is not compromised.
Data Verification: Thoroughly verify the integrity of restored data to ensure its accuracy and completeness.
System Reintegration: Gradually reintegrate cleaned systems back into the network while continuously monitoring for any signs of re-infection.
Communication and Reporting Phase:
Internal Communication: Keep key stakeholders informed about the status of the incident, actions taken, and progress towards resolution.
External Communication: If necessary, communicate with law enforcement, regulatory bodies, affected customers, and business partners, as required by law and company policy.
Public Relations: Prepare statements for public relations and communications teams to address media inquiries and manage the company’s public image.
Post-Incident Phase:
Debriefing: Conduct a thorough post-incident analysis to identify lessons learned and areas for improvement in the incident response process.
Documentation: Document all actions taken, evidence collected, and decisions made during the incident response for legal and regulatory purposes.
Continuous Improvement: Update the incident response plan based on the lessons learned to better prepare for future incidents.
Remember that ransomware attacks can vary significantly in terms of complexity and impact. It’s important to tailor this checklist to your organization’s specific needs and circumstances. Regular training, simulations, and staying up-to-date with the latest threat intelligence can significantly enhance your SOC’s ability to effectively respond to ransomware incidents.
If you are looking for SOC services, feel free to contact us via email info@cysys.io
In recent years, the threat of ransomware attacks has escalated, posing a significant risk to individuals and organizations worldwide. Ransomware is a type of malicious software that encrypts valuable data and demands a ransom payment in exchange for its release. This blog post explores the critical strategies and best practices for defending against ransomware attacks and safeguarding your digital assets.
Regular Data Backups: One of the most effective defenses against ransomware is maintaining regular and secure backups of your data. Ensure backups are stored offline or in an isolated network environment to prevent ransomware from infecting them. Regularly test your backup restoration process to guarantee data recovery in case of an attack.
Employee Training and Awareness: Human error remains a significant entry point for ransomware attacks. Educate your employees about phishing scams, suspicious email attachments, and unsafe browsing habits. Conduct regular training sessions to keep staff informed about the latest ransomware tactics.
Robust Endpoint Protection: Invest in advanced endpoint security solutions that include real-time threat detection, anti-malware software, and behavior-based analysis. Implement firewall and intrusion detection systems to prevent unauthorized access.
Patching and Software Updates: Regularly update operating systems, applications, and software with the latest security patches. Cybercriminals often exploit known vulnerabilities to deliver ransomware. Automated patch management tools can help streamline this process.
Network Segmentation: Divide your network into segments to limit the lateral movement of ransomware. This containment strategy prevents an isolated incident from spreading throughout your entire network.
Ransomware-Specific Tools: Consider using dedicated anti-ransomware tools that can detect and stop ransomware activity in real time. These tools often employ behavior analysis and machine learning to identify and block ransomware threats.
Incident Response Plan: Develop a comprehensive incident response plan that outlines the steps to take in case of a ransomware attack. Assign roles and responsibilities, establish communication protocols, and conduct regular drills to ensure a swift and coordinated response.
Zero Trust Architecture: Implement a zero-trust security model, where no user or device is trusted by default. This approach minimizes the attack surface and requires continuous authentication and authorization for access.
Encryption and Data Protection: Encrypt sensitive data both at rest and in transit. In the event of a breach, encrypted data is significantly harder for attackers to exploit.
Collaboration and Threat Intelligence: Stay informed about the latest ransomware threats and trends by collaborating with industry peers and sharing threat intelligence. Organizations that work together can collectively improve their defenses.
Please contact us via Support@cysys.io for more information on how we are providing services to SMBs to prevent ransomware attack from latest threat vectors.
This post aims to provide a core set of ideas for threat hunting — particularly in an intel-driven fashion which CN SYSTEMS follows in general. The intended audiences are detection engineers, threat hunters, and those aspiring to be one of the two.
It will also examine the traditional nomenclature of TTPs (Tactics, Techniques, and Procedures) and where time is spent hunting compared between the three.
Lastly, it will end with some smaller anecdotes and tips.
Caveats
We cannot stress this enough — MITRE ATT&CK is not a checklist — they even said so themselves. What this means practically, for this post, is that 100% MITRE coverage does not mean you are “secure”. It means that you can contextualize hunts and detections in a kill chain (more on this later).
To properly implement things discussed in this post, you will need process data (with command line), the ability to automate things (Python is recommended), and a VirusTotal Intelligence API key.
We are not suggesting the methods in here are the best it’s our best hypothesis way of hunting threats in your organization — or better than anything else — simply what has worked for us.
This content focuses heavily on hunting process data. Other styles of hunting (Yara/RFC violations/long-tail analysis/etc.) are definitely valid however not in scope.
MITRE ATT&CK Context
This post we will focus on Procedures rather than Techniques, so we want to give some examples.
Take T1566.001 for example. The tactic is Initial Access, the technique is Phishing: Spearphishing Attachment, and there are a ton of procedures listed. If I told you to hunt for this technique, there are a lot of ways to do it because the procedures vary widely; the payloads in the procedures include, but are not limited to, Word documents, Excel sheets, and PDFs. All of these payload behave slightly differently and will look different at the process level.
For this post, a procedure is any combination of programs, files, and/or arguments, that — when combined — achieve some technique. Here are a few spearphishing procedures:
Word (program) contacting a remote server for a template (file & argument)
Word (program) launching PowerShell (program) with “-enc” (argument)
Hunting “Known Bad” Procedures is Priority
Relying on the definition above, a known bad procedure is any combination of programs, files, and/or arguments that achieves some technique and has been documented to be used by a threat actor.
We can break this down into programs, arguments, and files:
bitsadmin.exe (program)
/transfer (argument)
http (argument)
ProgramData (file [path])
Temp (file [path])
Now if you wanted to build a hunt for this specific procedure, it would look for any time bitsadmin.exe ran with all of the arguments and file [paths] seen in the command line details.
However, where this level of granularity provides value is in breaking out the hunts and looking for any combination of the above:
bitsadmin.exe with “/transfer”
“/transfer” with “http”
bitsadmin.exe with “ProgramData”
“http” with “Temp”
etc.
By creating multiple smaller hunts, you still have a chance to catch the activity if APT10 changes their procedure, or if someone else uses a similar one.
Consider this, the goal of the procedure is likely Ingress Tool Transfer (downloading files) (see bitsadmin.exe transfer docs). So if APT10 alters their procedure — like by renaming bitsadmin.exe to svchost.exe — then the first hunt above won’t catch it but the next 3 will. Additionally, if they use a different binary to download it but still write to the same folder (and everything is supplied in the command line) then the third one will catch it.
That is the power of breaking a procedure down to its core artifacts and hunting for combinations of said artifacts. Not only will you catch the activity you were looking for but you will also catch slight variations. This way, you can be more confident in your ability to detect what you are interested in.
Not every potential combination of artifacts is a useful hunt. Some may produce unmanageable haystacks while others may simply produce irrelevant results. The trick is finding those combinations that provide coverage for more than one version of the procedure without bringing in too much noise. A easy way to do this is to focus on arguments (e.g. “/transfer” and “http”).
Have Reliable Sources of Intelligence
You need at least one source of known bad procedures that is regularly updated, trustworthy, and accurate. An easy answer here is MITRE ATT&CK.
our recommendation is to find a MITRE Group you want to hunt, using the MITRE Groups page, and open all of the references at the bottom of their listing. Take APT1 for example:
By reading through these, you are likely to gleam more technical data on their procedures and able to build hunts around them. I also walk through this in our post about hunting Lazarus Group.
Having a source of malware hashes specific to the threat actor and access to a VirusTotal Intelligence API key are crucial for scaling. You can extract “Processes Created” from VirusTotal’s Behavior information for a hash.
It shows vssadmin.exe deleting shadow copies. This would be considered a known bad procedure for WannaCry since it accomplished the goal of MITRE Technique T1490 (Inhibit System Recovery). If we apply the same logic here as we did for bitsamdin.exe and break this down to its core artifacts then we can build a series of hunts for this procedure and its variations.
Vssadmin.exe and “delete”
“delete” and “shadows”
Vssadmin.exe and “shadows”
etc.
By having a reliable source of known bad procedures — either from hands-on-keyboard operations or malware — and the ability to automatically extract them (e.g. VirusTotal API) one can build an extensive library of hunts for demonstrably malicious activity and its variations.
Contextualizing With MITRE
If you map each procedure you develop a hunt for, and any relevant ones you already had, to it’s MITRE Technique and Tactic then you can use the ATT&CK Navigator to visualize the change in coverage. Take the following example where a threat actor likes to use PowerShell to run payloads, Scheduled Tasks and BITS Jobs for persistence.
MITRE ATT&CK Navigator
If you let green be existing hunts and blue be new hunts, then you can see that prior to the most recent R&D cycle, you had hunts to catch the threat actor at Execution, Persistence, and Privilege Escalation and then the R&D cycle added hunts at Persistence and Defense Evasion.
Also, we are not claiming this method will catch the threat actor you are interested in; however, we suggest that creating multiple smaller hunts off one procedure using the method described above will increase you chances at catching them compared to creating one very specific hunt.
Know What You Are Paying For
If you take the total time spent on a single hunt/detection it can be broken down into 2 categories, R&D versus actually hunting through the results. Now generally speaking (again, for process data hunts) the more time spent in R&D means less time will be spent actually hunting it. This is because the more time spent in R&D tends to mean it is more specific. Looking at the hunts made above for bitsadmin.exe and vssadmin.exe, we spent our time making multiple hunts for known bad procedures which are unlikely to actually produce results unless suspicious activity occurs. Contrast that with just looking for all executions of bitsadmin.exe and vssadmin.exe; those take comparatively very little R&D but would take more time to review the results. This is roughly illustrated below as the “Temporal Costs of TTPs”.
Made with RapidTables
What this chart represents is that the core components of TTPs (Tactics, Techniques, and Procedures) impose temporal costs at different stages of hunting and by extension serve slightly different functions.
Firstly, Procedures cost more in R&D but take less time to hunt. Secondly, Tactics are typically easier to R&D but take longer to hunt due to larger result sets. Lastly, Techniques typically sit in a sort of middle ground between the two.
You get the opportunity to choose where to pay that cost and what you choose will largely depend on what you care about more:
Do you want to hunt in the unknown?
Or, do you want to hunt for known bad?
One is not better than the other. That is the crux of this illustration. However, I do hope this at least gives you an additional (and valuable) consideration when writing hunts and detections.
Admittedly, we are sure most of SOC analysts, hunters, and detection engineers intuitively know that the more specific you make your hunts (the more time you spend in R&D) the less results you will have. That’s just natural — the more specific your criteria, the less results fit those criteria. However, we have never seen it specifically called out and we find this framing of hunt to be useful in managing priorities. we are concerned about all PowerShell abuse? Or just how APT X tends to abuse PowerShell? The answer will vary depending on multiple things, but the answer will also inform us of how the time is about to be spent and we get to choose what is most effective for the situation at hand.
Known Bad vs Unknown
When we started out in Blue Team work, we heard over and over that threat hunting was looking at the unknown. While we think the sentiment is nice, we never really found much utility in the statement. we would have heard “you have to know what is normal to find the abnormal” and that was not a particularly encouraging statement because it implied, we to know a lot about a lot to even get started. Don’t get us wrong, it is a valid approach, we just did not find it very helpful.
So instead, we took the route of studying the known bad. we thought we would modify the adage to something like, “you must be able to recognize the abnormal when you see it”.
As we said earlier that hunting Tactics, Techniques, and Procedures serve different functions — this is where that comes in. Kind of by definition, to hunt the unknown (very broadly), you are also hunting a tactic. For example, say you are looking at all commands ran on a file server (tactic: Collection) — you are looking at the unknown. As you move over to a Technique like Data From Local System (T1005) you might focus on SCP and FTP commands — you are moving closer to known bad procedures. Finally, the last step would be looking for a variation of a known bad procedure you were interested in and sourced from a threat actor or malware sample. An example of this might be SCP commands that copy specific directories.
Sort Your Data
It sounds trivial but hands down the easiest way to make a long list of potentially suspicious commands more digestible to hunt is to sort them alphabetically.
At first, sorting alphabetically makes almost no sense. It seems as if sorting by user or device would be better. However, in hunting the unknown, sorting processes alphabetically tends to group similar processes together (whether by their process name, folder path, or arguments) allowing you to more easily identify outliers.
Sorting this way does not require you to actually know what the known good commands are doing, only to recognize common procedures and that those are likely benign; so, focus on the others.
Yes, some threat actors are experts at hiding in the noise. Some will absolutely spend the time to craft a legitimate looking DLL and/or software package to blend in with really common procedures in the environment. However, every hunt you have that is a variation of their known procedures is another trip wire on their path. There are threat actors that are exceptionally hard to hunt in this manner (because they craft every procedure to blend in with the noise) but that appears to be the exception, not the rule; most tend to have a least a few procedures that can be distinguished from normal day-to-day operations. In those rare cases where the threat actor blends in well, hunting in the unknown and being more attentive to detail than normal is almost necessary.
You Probably Knew This Already
As we touched on earlier, we fully recognize that most people who have experience in a SOC probably already know the things that have been discussed here — whether they were consciously aware of this knowledge or not. However, we do think it is still important to shed some light on some of the more fundamental parts of hunting, challenge some ideas, and introduce new ones that break this discipline down into learnable chunks.
At the core of all this is one principle — threat hunting is achievable — and it is not just learning common TTPs and how to detect them. It is sometimes referred to as “the art of threat hunting”. A threat hunter can absolutely be compared to an artist, because they can both have their preferred style. However, threat hunting itself is a skill, just like painting.
If you are looking for a Threat Hunting Services Please feel free to contact us via email support@cysys.io
A business continuity recovery strategy is an approach selected to determine recovery and continuity options in the face of a disaster or other business disruptions. There are 4 main types of plans as follows:
Emergency Response Plan provides guidance for dealing with physical emergencies in order to minimize the impact of the event and promote the safety of people and facilities.
Crisis Management Plan A strategic plan that guides top management during a crisis and provides guidance on communications to those affected by the crisis including employees and families as well as stakeholders and members of the media.
Business Continuity Plan guides an organization to respond to disruption and resume, recover and restore the delivery of products and services consistent with its business continuity objectives.
IT Disaster Recovery Plan guides the technology recovery teams and provides the procedures required to enable recovery or availability of vital technology infrastructure during times of disruption.
CY SYSTEMs provide these plans to provide solutions that can be undertaken to recover the time-critical activities/processes and improve mitigation measures to reduce the impact of disruptions.
Please feel free to contact Us via email support@cysys.io or fill out the below form with your details.
Everyone agrees that there are difficulties in finding qualified people for the SOC environment. As a result of our research, there are some reports published on this subject, and according to these reports, the important causes of the problem are burnout, overwork, and a stressful working environment. When the remote working model, which has become a part of our lives during the pandemic period, cannot be managed correctly, it becomes more and more difficult to recruit high-skilled people, considering that there is a lot of overtime for SOC analysts and Incident Responders.
During the incident response preparation process, you must ensure that your SOC team has sufficient technical knowledge, and you must provide training to close any gaps. In general, when you want to prepare or choose a training program for your SOC team, you should consider the following factors.
Set a GOAL
You need to clearly define what you expect your team to achieve after training. Your goal may be that the team can easily resolve different alerts, decrease SLAs (average response time to threats), increase malware analysis skills, etc. After determining your goal(s), the flow of the training program you will choose/create will be clearer.
It is also important to pay attention to which team you are creating the training for. While offensive-oriented training will be suitable for the red team, it will be better for your blue team to focus on specific areas of the blue team. It would be better if separate teams are involved in different training programs if there are no major budget problems.
Establish a BASELINE
You need a baseline to accurately measure the output of your training. For example, you want to reduce the team’s response time to threats, but if you do not know the average time for today, you cannot understand whether the training is working or not. With an accurate assessment, you need to measure your team’s skills and the level they are at now.
SIMULATIONS
A SOC training program must definitely include simulated cyber-attacks. Thus, the trained analyst detects and analyzes various threats by considering himself in the company’s SOC environment. Thanks to the simulation environment, mistakes to be made do not affect real people and institutions.
Please feel free to contact us via email for more information about Cy SYSTEMS SIMULATIONS support@cysys.io
Update to REALISTIC TRANING
Make sure that the concept and content of the training are relevant to the real-life situations that the team will encounter (alert investigation, log analysis, malware analysis, etc). At the same time, make sure that it is a program that conceptually handles current vulnerabilities such as Exchange RCE, Log4j, Spring4Shell, etc. Otherwise, the training you will purchase/install will not attract the attention of the SOC team and will create different excuses for not completing it.
Please feel free to contact us via email for more information about Cy SYSTEMS TRAININNG PROGRAMMES SIMULATIONS support@cysys.io
One final Thing DOCUMENTATIONS
A SOC member’s job, however technical, can be effective to some extent that he or she can document the incidents well. The created documents will help the SOC team to be on the same page, helping to determine the consistency of the analyzes made as well as the progress of the team. For these reasons, programs that support soft skills, as well as technical skills, should be preferred. For example, you can consider the following courses:
Writing a Report on Security Incident
How to Prepare a Cyber Crisis Management Plan?
How to Create Incident Response Plan?
If you are in the process of evaluating a training program, you can make an easier decision by looking for answers to the questions below.
Will this training give my SOC team the confidence to handle different types of threats?
Does it cover new threats (Log4j, Dog-Walk, Spring4Shell, Proxy4Shell, etc.)?
Will they learn to use the right tools and processes at the right time?
Does the training add value to the daily work routine of a SOC member?
Does it offer SOC simulation for effective learning?
Please feel free to contact us via form or email support@cysys.io
