Intrusion Detection & incident response

11 minute read

Updated:

15. Intrusion Detection & incident response

Objectives

  • To understand the basic principles of intrusion detection and see examples of how network based intrusion detection can be done.
  • To appreciate the role of honeypots in detecting intrusions and studying attacker behaviour
  • To learn two approaches to collect evidence of attack from a computer system
  • To see how we analyse a suspicious executable

The challenge

  • you have behaviour that legit users have on system, and behaviour of intruders two are not completely different sets, there are some overlaps of what they’d do.
    • Overlaps mean that you cannot easily distinguish legitimate users to intruders
  • Intrusion detection also the idea of compromise
    • If you lose interpretation of true behaviour, then you catch more intruders but more false positives
      • False positive – legit action that is accidently flagged as intrusion
    • If you have very tight implementation with tight threshold, then u’ll miss some intruder activity false negative
  • It’s a challenge and can’t combine perfectly but there are approaches

Intrusion detection approaches

  • Statistical anomaly detection
    • Based on analysing activates of legitimate users over time filling up the statistical model of what that behaviour is
    • And test for any observed behaviour to see how well it fits the model. If tis beyond the threshold form that model flag it as a potential intruder
  • Rule-based detection
    • you define set of rules which you derive manually by looking at legit user patterns and you just test to see if they’ve violated. If violated flagged as suspicious case, but isn’t confirmed as intrusion
  • If we are dealing with intrusion that already happened, we need to use system logs. Attacker when they break into the system, they will try to erase their presence. So secure system log is v imp

Network based IDS

  • There are range of tools available for network intrusion detection
  • SNORT and BRO - They both monitor network traffic of suspicious events and use rule based approach, looking at specific pieces of network traffic to see if its suspicious or not

A network IDS: Snort

  • It analyses the packet in real time, you can configure network interface accordingly to capture all the traffic and can run snort on that traffic OR can capture documented file and then do block by analysis
  • Can handle defragmenting IP packets which is fragmented to travel through network with small MTU and attackers might deliberately do that to avoid detection
    • It reassembles packets into whole form and analyse them
  • Can also reassemble TCP stream in order
  • Can detect port scan
    • Sending sequence of port number is a obvious signature
  • This is a one-use standard - If exploit becomes a public knowledge, you will find snort rules being published within hours of the exploit so that it can deploy to detect intrusions that are happening.

Rule Examples

  • image
    1. Specification of what’s happening in the network – UDP traffic happening in any prot and any address
    2. Particular subnet specifying IP addresses you are monitoring
    3. Port number that its targeting
  • In this e.g. we are:
    • Looking for any UDP from anywhere on that subnet 192.168.. on port 31337 – port no is significant bc particular type of malware is configured for certain ports i.e for trojan
    • 31337 – trojan attacks. Can gets installed and listens to what’s happening in that port. If we get any udp traffic on that port, it might be innocent or might be an attacker
  • image
  • Alert any TCP traffic coming from anywhere, arriving anywhere on any port, but we are looking for content – we are looking for traffic with four 90 hex values
    • Hex 90 is a opcode for null operation on intel CPU – and this is used as part of a sandwich (buffer overrun) for safe landing zone. And you might suspect this so we put msg saying ‘shellcode’?
  • The main problem for this is that its not specific enough – its flagging anything with hex 90! but could be innocent! quite a few false positives
  • Also, if you are looking for signatures that might specific malicious traffic, the attacker will try to disguise them

Evading Detection

  • Red box - Couple of hex 90, then you got 2 exchange op to change register values which does nothing!!!
    • This is another way of doing null operation.
  • you can break up NOP sleds which could be suspicious if its long, and this is the virus signature that is hard to detect

Host-Based IDS

  • To run sth on a machine to look for intrusion – in disk that is not supposed to be there
  • Tripwire
    • Creates and stores secure checksums of critical systems files to detect whether or not these files have been tampered with during attack
    • It does this by hashing, HMAC, or digital signature
    • you build a db of hashes for a system and you periodically check that those hashes haven’t changed. But for exe don’t change generally. If you upgrade the application you need to recompute and update db
    • It can’t detect network activities. It can only detect impact of intrusion where the attacker has replaced an executable program on top of the victim’s machine with malicious version of exe.

Host-Based IDS: Honeypots

  • A resource that you put there to be attacked – unlike production system that you don’t wanna be attacked, honeypot is a resource you put honeypot on the network to be attacked.
  • The point is there’s nothing imp happening on that machine – so if it gets attacked, you know if anything is happening on that, it’s a malicious activity since there’s no legitimate user
  • Looking to in honeypot is to monitor what’s going on – who’s logging in and what they do.
  • Can protect production system or as a research tool
  • Production
    • As an intrusion detection system (IDS)
    • Evidence collection
    • Problem with IDS where you collect everything, is that attacker log is buried in long log – so you need to filter and find the ones that are hard. But with honeypot, it will only collect the malicious stuff! Easier to collect evidence of what’s happening
  • Research
    • If you want to capture malware like worms
    • To observe new tools and techniques on how they attack
    • Investigate how attackers break into the system - attacker behaviour

Interaction level

  • Low interaction honeypot
    • Not very believable
    • It listens on standard ports and they give limited and superficially believable response
    • A bit of work by attacker will reveal that its fake as it doesn’t respond as believably
  • High interaction
    • More believable as it is full-blown OS and full suite of apps
    • Much better learning for attacker behaviour coz it keeps hook for longer
    • If the attacker could break the sandbox, it’s dangerous
  • Trade-off – more info on what the attacker is doing but is more dangerous as they could do sth malicious

Benefits & drawbacks

  • Benefits
    • If you are looking at firewall logs, you are gonna have false positives and have lots to filter through – you need specialized filter on those logs or you use honeypot for higher quality data
      • Honeypot – simple to set up. No rules and signature db to maintain
  • Drawback
    • It only represents one point of the system narrow field of view.
    • Might skip honeypot and move onto other parts of the network
    • Difficulty of accurate simulation with low interaction honeypot
    • Risk of high interaction honeypots can be used to mount attacks
  • E.g. Spector – GUI of honeypot that runs on windows system
    • It can pretend to be a different OS like mac, Linux, but the underlying system is that of windows. So sufficient work by attacker will reveal that its running on windows.
    • Can superficially fool ppl – you select what machine you wanna simulate, set up character, services, and can provide fake passwords (for a reason) and also have warning password - when the attacker cracks that, it warns saying ‘we know what you are doing!’

Incident response

  • All those tools for detecting what’s happening to see what attacker is doing. But what do you do if its already happened? How do you respond to it?
  • More of a forensic analysis of the system
  • We want to know
    • How did they get in and what did they exploit to get into the system
    • And once they are in the system, what were they able to do
  • You want to gain evidence of criminal activity as they must’ve broken a rule, but we might be able to catch them! We need evidence to prosecute then

Approaches

  • We are dealing with post-mortem analysis data is non-volatile – it can be found on disk and system logs
  • Whereas if we are dealing with live response
    • Then we have possibility of volatile data – what’s in memory of the machine. So you don’t wanna turn off the machine to lose it!! But it could’ve been rebooted so we already lost certain amount
  • Network based evidence collection
    • Network logs need to be looked at.

Post-mortem analysis steps

  • Series of step – need to be careful as we need to collect evidence that is a result of attacker and not caused by anyone else!
  • you wanna make sure you don’t modify the evidence on the system as it is harder to prosecute somebody
  1. Forensic duplication – ensuring we have a safe copy
    • We got a machine that’s been attacked, and we need to analyse the disk. We first remove the drive and duplicate it. And we form all analysis on duplicate so that we preserve the original drive in a safe place and we’ve not tampered it accidently
    • Use specialised connector – coz you don’t wanna accidently write to the evidence drive. It has wires that are deliberately removed so that it’s read only. hardware-based write blocking
    • They allow hot-swapping – you got several machines and you wanna hot swap
  2. Recovery of deleted data
    • When you delete sth, it doesn’t acc get deleted – Removing a file is rather slow if every bit of file has to be wiped in the disk. So what we do in OS is to break the link between file metadata and disk blocks that hold contents of the file, as if we don’t have the metadata you can no longer find the file.
    • Now the disk block is flagged as ‘free’ and OS is free to write over them and use new file – data persists on disk. so deleted file is usually there until the flag gets reused. But it takes a period of time
    • For small server, research found that sth could last for 12-35 days until the disk is needed, there might be bits of file still lingering on the disk
    • you want to recover this by scanning the disk in low level to see what’s there
    • Then, how do you properly delete them?
      • you overwrite the blocks and write sequence of random bytes.
  3. Collection of MACtimes
    • Once uve copied the evidence drive, you want to capture when things were modified.
    • Unix – 3 diff time stamps
      • Mtime- modification time, atime- access time, ctime – status change time
      • And similar timestamps in other OS
    • Idea is if you can check when file has last been accessed or modified – if it’s a file that shouldn’t be modified and its been modified and if it falls btwn the time window that attack has took place – likely it’s from them
    • Problem is this can be lost by reboot and system backup so earlier you do this, is better
  4. Computation of file hashes
    • You need to compute hashes of everything of the disk partition and deleted individual files u’ve recovered
    • You can use standard tools on Linux such as sha256sum simple to do
    • Why do we need this?
      • To check whether or not there’s anything malicious by comparing to original db
      • To make sure that we haven’t accidently modified anything !!!! you have a reference point that you can go back to and check if the hash has changed
  5. Removal of known files
    • A large no of files probably won’t be useful for you - so delete files that’s not interesting
    • you can compute hash of the expected version of each applications and standard system files stored on the OS
    • And you can build up db of hashes for known files and compare everything on duplicate with that db – if hashes match, its not been changed and you can delete it
    • Doesn’t guarantee, but it tells you to look more closely to it. Narrowing to things that may be suspicious

  6. Analysis of Executables

    • Hopefully you have few candidates of suspicious things
    • you need to understand what that malware is and what it does
    1. Static analysis – not running the program
      • It’s clear that its not a normal program behaviour. what is it then? Why does it look garbage?
        • Could’ve used encryption and compression !! compression hence some part was legible
        • Then we go dynamic
    2. Dynamic analysis
      • you run it in a separate machine and you wanna sandbox as much as you want
      • More careful and you wanna run it on a virtualisation software so that it doesn’t spread
      • Trace system and library calls
      • Step through the code in a debugger

Live response: Volatile data

  • Data you can capture while the attack is still happening
  • System date and time
  • Running processes, process memory dumps
  • Running services and loaded kernel modules
  • Scheduled jobs
  • Network connections and open ports
  • Executables that have opened ports
  • Opened files
  • Users currently logged on

Live response: Approach

  • Must adhere to the ‘Order Of Volatility Principle’ – capturing most volatile data first, and least volatile last
  • Evidence collection tools must be trustworthy and self-contained
  • Typical approach is to run the tools directly from a CD containing executables and libraries
  • Data can be transferred from victim to forensic workstation via the network, using netcat
    • Hash of any captured evidence should be computed immediately before anything changes

Summary

  • Considered some of the principles behind automated intrusion detection
  • Explored the use of network based and host-based IDS
  • Discusses how to conduct a post-mortem analysis of an attacked computer system
  • Investigated an example of a suspicious executable

Leave a comment