Please enable JavaScript.

Coggle requires JavaScript to display documents.

Hacking Tools-Techniques-Exploits-IncidentHandling - Coggle Diagram

- - - - Software / Hardware
      - Communication
      - Data
      - Supplies , Transportation
      - Policy
      - Space , Documentation
      - People
      - Power & environmental controls
      - Elements needed to prepare the team for an incidents, Fundamental of contingency planning
      - People
        
        Regularly test your users with social engg calls & phishing tests - your users populations susceptibility to clicking the malicious links
        
        Caller ID spoofing is a good test to employ
        
        Reoccurring training can be big help - constant reinforcement
        
        Prj & services like sptoolkit & phishme are excellent ways to create phishing campaign & track the results
        
        The most easily attacked - via targeted email [ spear phishing]
        via calls (social engg)
      - Policy: Warning banners
        
        Have legal team review the banner- be careful on local privacy laws, especially in Europe
        
        Banner is one tool that can be used to define your org policy on the presumption of privacy
        
        Establish policy & warning banners -
        
        Response Strategies
        
        Maintain secrecy or notify law enforcement. Get management buy-in & sign-off for your def practice
        
        Contain the incident & cleanup or watch the attackers & try to gather mode evidence & learn
        
        Decide generally how will you handle the "big issues" up front
        
        Notifying Law enforcement
        
        Many jurisdiction have breach notif laws : PII - PHI
        
        Optional reasons: to benefit from criminal disc process - to be good corporate citizen
        
        Requirement varies by jurisdiction
        
        Threat to public health
        
        Substantial impact on third part
        
        Legal req based on industry
        
        Peer Notification
        
        Establish a policy for outside "peer" notif
        
        Dealing with incidents involving remote computer belonging to , business partn, your com, your employee,contractors & other employees are are not full tim
- - - - Incident handlers can analyze app logs to get a feel for unusual activity that could be associated with an attack that sometimes cannot be discerned by looking at the other layers of identification. they sould ensure they have access to app log data - vital elements are dates,timestamps,users,(especially admin lvl account) & action/trxn should all be recorded for later analysis
      - Incident handlers should make sure they have access to attack identification information across all the 4 levls - NW,host,Hostlevel& app lvl
      - A handy list of legitimate & malicious use of ports can be found at http://sppedguide.net/ports/php
      - To help improve identification process - refer intrusion detection cheat sheets: https://www.sans.org/posters/intrusion-discovery-cheat-sheet-for-linux/
      - How to find out if the service is running? try "lsof -i" or netstat -a on win plus linux
      - Does the destination host run the service? are you sure? is it included in your asset inventory list - if not, this probably doesnt indicate a good job of reconnaissance on the attackers part & the risk is probably very low on the other hand, if it looks like the attacker what she is looking for, you may be in some trouble
      - When you determine a listening port no,you should look up the port to see its official assignment, as well as potential use of that port. list is maintained by IANA
    - - When looking at the situation, you need to determine how much damage could be caused:
      - How widely deployed is the affected application/platform?
        What is the effect of vulnerability is exploit if the vul is present?
        what is the value of systems impacted ? data on those systems
        can it be remotely exploited,is an exploit available
      - What is the effect of vulnerability, can it be remotely exploited,is an exploit available, or is this is zero-day attack (attack that was previously unannounced)- these helps handler to come to reasonable initial assessment
      - One of the most effective tools to assist in incident response is MITRE Att&CK matrix.
      - Important responsibilities of senior handler is to maintain situational awareness
      - Lenny Zeltser have cheat-sheet- helpful to responding to sec incidents https://zeltser.com/security-incident-questionnaire-cheat-sheet/
      - Imp function of incident handler is to continue to assess the data/system to see if it it indicates that this could be something other than incident.
      - Process should be optimized to encourage reporting & then deal with false positive gracefully & efficiently
  - - - Disconnect NW cable
      - Pull the power cable
      - Some possible ST containment actions:
      - ISolate the switch ports so the system cannot send/recv data. Change a name in DNS to point to dff ip address
      - Try to prevent the attacker from causing more damage - while minimizing the changes to data on system(s)
      - We want to keep the target machines drive image intact until we can bck it up
      - If short term containments disables the syst - make sure you advise someone in the business unit responsible for the sys
    - - Grab an image of memory as well FS
      - One of the most pop tools for creating binary images on nix is dd.
      - Make forensics images of affected sys as soon as is practical - as a source for forensics analysis.
      - Volatility framework & Rekal can capture & analyze mem
    - - Review logs from neighboring system
      - Do you down the box? is this a contain? & clean or a watch or learn? The ultimate decision of downing the sys is business call . Make a recomendation which should be signed memo to the business owner of the machine
      - Acquire logs & other sources of info- How far did the attacker get?
    - - We fully eradicates the attackers artifacts, possible by rebuilding sys or restoring it frm backp.
      - Once we got our bckp for forensics analysis, we can start making changes to sys
      - Potential Actions include
        
        Insert IPS or inline Snort/Suricata which can block some attacker activity
        
        Null routing - config router to drop pckts associated with given source or desti add used in attack
        
        Patch the sys & possibly neighboring sys - if the attacker compromised it by exploiting the vul
        
        Change password - to disconn in the attackers access
        
        Apply FW & router filter rules
        
        remove accnts created by bad guy & kill any processes that offer the attacker backdoor access to the machine
        
        Continue to consult with System owners
        
        Dont play the blame game
        Never allow fault to be an issue during the incident handling
        Assigning fault now closes down imp avenues of inventigation
        Sometimes, as you learn more, assumptions changes
        If fault absolutely must be assigned, do that during LLP, not containment phase
        
        Keep system owners & admins briefed on progress
    - - Incident Category:
        Denial of service, Compromised Info, Compromised Asset, Internal Hacking,External Hacking, Malware, Policy Violations
        https://www.first.org/resources/guides/csirt_case_classification.html
      - Criticality:
        Level 1- Business crti systems, 60 minutes respo tim
        Level 2- Non-business crit system 4
        Level 3- Possible Incident, non bus crit 48
    - - Always let them know that you are in incident mode
      - At 10 or so minutes into the incidents, i realized i was over my head & needed reinforcements or specialist. As soon as incident is identified, you may wish to put them on alert.
      - When you declare an incident, notify your management & get help to assist in incident handling process- CISO CIO.
    - - Everything is reported to helpdesk / incident handling center should be given trouble ticket
      - Remember Horizontal reporting: communicate closely with sysadmim / helpdesk shops
      - Make sure both groups sec & line management are kept in loop throughout the incident
      - Remember Vertical reporting
      - Inform impacted business unit
      - Create an entry in incident tracking system
  - - - Although it is certainly true that total destruction of contents of disk takes care of any malevolent code, the opportunity for reinfection via same channel after you reload OS still exist
      - The best course of action is to determine what the cause of the incident was, to find the vector of infection, and to take action to prevent this from happening again
      - Reformat/reinstall OS from scratch may be considered a valuable shrtcut in handling process
      - With the bleeding stooped, the goal of the eradication phase is to get rid of the attackers artifacts on the machine, including accunts, mali code, anything else bad guy left on machine
    - - Locate the most recent clean backup
      - Recovery is the matter of wiping the drive ( zeroing it out), reformatting the drive, reinstalling the OS, reloading the data frm bckup & fixing the vul that caused the problem in first place
      - Without a complete reformat, attackers residual data, tools & access may linger
    - - Encourage the imapctd business unit to rebuild - reviewed by the CST
      - Its common for attacker to use legitimate services like RDP , SSH, t persist & spread it is vital to monitor logs of these servces for irregularities like strange IP, multiple concurrent logins from single UID
      - If the attacker change the OS itself by installing a rootkit, you should rebuild from og install media & install patches. Make sure you patch the system thoroughly, or the attacker will return
      - Remove malware inserted by attacker - ex viruses- but dealing with virusus that dont yet have antivirus sig is a much harder prob
    - - Sec of affected system to be upgraded
      - If we do not remove vul - sys may be compromised again
      - Implement appropriate protection tech: fw, router,filters, moving sys to new name/ip.null routing particular IP, applying patches & hardening sys
    - - Is possible, scan your entire NW for interesting ports with a port scanner
      - Running a sec scanner on neighboring sys in a compromised can help u make sure you have full & complete eradication.
      - Perform VA
  - - - Validate the sys- Once systm have been restored, verify that the ops was successful & sys i bck to normal
      - Run through the tests,or better yet, have the buss unit retest
      - Goal of recovery phase is to put the impacted sys back into prod in a safe maner
    - - Decision of when to put the sys back into business has to be made by sys owner- you can give advice to try for an off-hour time slot
      - You will be often overruled on this, with the business opting to restore srvc immediately once sys are rebuilt & ready
    - - Utilize NW Hbased IDS IPS. If possible, create a custom sig to trigger on the original attack vector because attackers will likely try the same thing again
      - carefully check OS & app logs
      - Once system is back online, continue to monitor for backdoors that escaped detection
      - Sometimes you never discovered abt the attack vector , & the prob comes back
    - - We need to look for these changes aggresively to detect the attackers return
      - We urge handlers to write up one or more simple scrpt that they can run on daily basis to look for artifacts left by attacker in previous compromise cycle
      - NOt alaways using malware, sometimes logging in via normal mech
      - If attackers come back & create the same artifacts again, your script should detect teh fact & notify you
      - Most humn attackers that compromise machines do return to the scene, making same or similar changes to sys that they made upon initial compromise
      - https://blog.commandlinekungfu.com
      - One of the most imp things for incident handlers to do in the recovery phase & in the months following an incident is to check regularly to see if attacker has returned
  - - - It takes disciple to do the report.It takes even more to attend LLM
      - One way to improve is to learn from mistakes & move on to make new mistakes instead of repeating the old ones. This is the prmy purpose of follow-up part of the process
      - While that incident was ongoing, you had that Adrenalin & now it is worn off & u r tired
    - - Develop a follow-up report. Handler submits the draft to the head of Inc handling team. Chief edits the doc & interacts with the handler to make sure the doc reflects what actually occured, in light of org culture
      - Encourage all affected parties to review the draft.Have everyone involved in handling the incident signoff on the rep, agreeing to its contents. attempt to reach consensus & get sign-off
      - Goal of LL phase is to document what happened & improve our capabilities.
      - If anyone has a strong disagreement abt the facts of matter.he can submit that, and his statement can remain a part of the incident record.
    - - What is most imp thing for an executive summ to cover? How much org saved by having an effective incident handling procedure &team!
      - Meeting occur within 2 weeks of resuming prod
      - After the report has been reviewed, schedule a LL meeting. In general, the main purpose of such a meeting is to get consensus on executive summary section of rep.
      - During incidents, mistake occur. We learn from these, improve our process for future & move on. sometimes we run into policy or other org problem that hinder bringing the incident to close.
      - We note these & submits them to management for its consideration
      - This is valuable tool for process improvement. Not to blame people. focus should be on process improvement
    - - This may mean an alteration to the process or tec in your env - get approval funding to fix
      - When trying to improve , you will want to do RCA. This involves looking beyond just the immediate prob, and trying to find out why such a prob could even occur
      - You go to mgmt & make a compelling case for fixing that caused the incident in first place
      - Ex: lets assume an attacker was able to gain access to sys because of weak passwrd. Obviosuly u wnt to change the passwrd, examined the compromised sys. Howerver, its imp to ask why a weak passwrd was able to be used in first place?
      - We want to have constant improvement so the cause of incident can be eliminated or minimized
      - Was there no password policy to begin with?
        perhaps there is passwrd policy, but it wasnt properly enforcesd on the sys attacker compromised
      - Or perhaps there is a passwrd policy, & it was enforced but the policy unintentional allows weak passwrd
      - Do this type of process cz diff underlying causes req diff solution