Mr Wolf is an incident responder: - He knows what to do: experience, knwolege - Yet, he does nothing: he tells what to do (technics are much better than you to run commands, and they know better their system) - Mr Wolf "calm the room down"
All incidents are events, but not all events are incidents. Incidents refer to the more specific events that cause harm to your environment. Security incidents typically happen less often than cybersecurity events. A security incident always has consequences for the organization. If an event causes a data or privacy breach, it immediately gets classified as an incident. Incidents must get identified, recorded, and remediated. This is why monitoring security events is so important. Organizations must take a proactive approach to lookout for events that could cause serious problems.
These names and steps are common for all of us. You are expected to know these steps, what to do in each of them and when you must take the next step! During the next sections we will explore these steps in depth. Next, there is a summary of them:∫ 1. Preparation—review and codify an organizational security policy, perform a risk assessment, identify sensitive assets, define which are critical security incidents the team should focus on, and build a Computer Security Incident Response Team (CSIRT). 2. Identification—monitor IT systems and detect deviations from normal operations, and see if they represent actual security incidents. When an incident is discovered, collect additional evidence, establish its type and severity, and document everything. 3. Containment—perform short-term containment, for example by isolating the network segment that is under attack. Then focus on long-term containment, which involves temporary fixes to allow systems to be used in production, while rebuilding clean systems. 4. Eradication—remove malware from all affected systems, identify the root cause of the attack, and take action to prevent similar attacks in the future. 5. Recovery—bring affected production systems back online carefully, to prevent additional attacks. Test, verify and monitor affected systems to ensure they are back to normal activity. 6. Lessons learned—no later than two weeks from the end of the incident, perform a retrospective of the incident. Prepare complete documentation of the incident, investigate the incident further, understand what was done to contain it and whether anything in the incident response process could be improved.
In this section, we are going to do a Capture the Flag exercise You need training, and you must be fully trained when an incident occurs. You MUST use CTF exercises to train youself. There are many open and paid CTF exercises, be sure to do several of them every year to keep your skills sharp! In a CTF you usually have a limited time to resolve an incident. An incident is solved when you answer a specific question like "which user downlaoded a file" or "whats the identifier of a file in the /root directory". Hence the name: these are flags, and you must capture them
This is my proposal for today. It is an easy CTF that can be solved in an hour with the rigth tools. Check the reference section for more CTFs.
Logs are huge and you don't know all possible threats. Manually inspection of the Windows log system is not alware possible or efficient. Any automatic tool that can assist in the process of finding IOCs is wellcome There are many alternatives. This slide presents Chainsaw and also includes Hayabusa and APT-Hunder. You must use any tool with a database updated to the last threats, probably using yara or sigma rules
A5: finance A6: Excel A7: rlvq27rmjej02sfvb.com - Check the complete path of the file: C:\Users\finance\IEUDLK.CJF - Check payload 3 in timeline explorer: C:\Program Files (x86)\Microsoft Office\root\Office16\EXCEL.EXE