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
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
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
In today’s rapidly evolving digital landscape, organizations face an ever-increasing number of cyber threats that can wreak havoc on their systems, data, and reputation. In response to these challenges, the Center for Internet Security (CIS) has developed a set of best practices known as the CIS Controls. These controls serve as a powerful framework to fortify an organization’s security posture and ensure robust protection against cyber threats. In this blog post, we will explore how CIS Controls positively impact organizations in terms of security.
What are CIS Controls?
The CIS Controls are a prioritized set of actions designed to safeguard against the most prevalent cyber threats. Developed through collaboration between government, industry experts, and the cybersecurity community, these controls are continually updated to stay relevant in the face of emerging threats. They provide a structured and practical approach for organizations to enhance their security infrastructure and defense mechanisms.
The Impact of CIS Controls on Organizational Security
Comprehensive Risk Management: CIS Controls offer a comprehensive approach to risk management. By identifying and prioritizing security measures, organizations can allocate resources efficiently, focusing on critical areas that are most susceptible to attacks. This enables them to be proactive in their defense strategy and effectively respond to security incidents.
Minimize Vulnerabilities: CIS Controls provide a systematic way of assessing and mitigating vulnerabilities within an organization’s network and systems. Regular vulnerability assessments, patch management, and secure configurations help minimize the attack surface, making it significantly harder for threat actors to exploit weaknesses.
Improved Incident Response: The CIS Controls include guidelines for establishing an effective incident response plan. By implementing this framework, organizations can detect and respond to security incidents promptly, reducing the time it takes to contain and mitigate the impact of an attack. Swift incident response minimizes potential damage and prevents data breaches from spiraling out of control.
Enhanced Employee Awareness: CIS Controls emphasize the importance of cybersecurity awareness training for employees. Organizations that prioritize cybersecurity education cultivate a security-conscious culture. Employees become better equipped to recognize and report potential threats, thus acting as a first line of defense against social engineering and phishing attacks.
Compliance and Governance: Adhering to CIS Controls can help organizations meet various regulatory compliance requirements, such as the General Data Protection Regulation (GDPR) and the Health Insurance Portability and Accountability Act (HIPAA). By aligning with these controls, organizations can demonstrate their commitment to maintaining a secure environment for sensitive data and gain the trust of customers and partners.
Third-party Risk Management: The CIS Controls emphasize the importance of assessing the security practices of third-party vendors and partners. With many security breaches originating from third-party vulnerabilities, adopting these controls enables organizations to minimize the risks associated with outsourcing critical functions.
Continuous Improvement: CIS Controls promote a cyclical approach to cybersecurity, encouraging organizations to continuously review and improve their security practices. By regularly updating and adapting to emerging threats, organizations can stay ahead of cybercriminals and maintain a robust security posture over time.
Conclusion
In conclusion, the CIS Controls play a pivotal role in enhancing an organization’s security by providing a structured and prioritized approach to cybersecurity. These controls enable organizations to identify vulnerabilities, respond effectively to incidents, and cultivate a security-focused culture. By aligning with the CIS Controls, organizations can significantly reduce the likelihood of successful cyber-attacks, safeguard their assets, and build trust with stakeholders. Embracing these best practices is essential in an increasingly interconnected and vulnerable digital landscape.
