SlideShare a Scribd company logo

CNIT 152: 9 Network Evidence

•
•
Sam Bowne
Sam Bowne

Slides for a college course based on "Incident Response & Computer Forensics, Third Edition" by by Jason Luttgens, Matthew Pepe, and Kevin Mandia, at City College San Francisco. Website: https://samsclass.info/152/152_F18.shtml

Related slideshows

CNIT 152: 10 Enterprise Services
CNIT 152: 10 Enterprise ServicesCNIT 152: 10 Enterprise Services
CNIT 152: 10 Enterprise Services
 
CNIT 121: 10 Enterprise Services
CNIT 121: 10 Enterprise ServicesCNIT 121: 10 Enterprise Services
CNIT 121: 10 Enterprise Services
 
CNIT 152 13 Investigating Mac OS X Systems
CNIT 152 13 Investigating Mac OS X SystemsCNIT 152 13 Investigating Mac OS X Systems
CNIT 152 13 Investigating Mac OS X Systems
 
1 of 61
Download to read offline
CNIT 152: Incident Response 9 Network Evidence Updated 10-8-18
The Case for Network Monitoring
Types of Network Monitoring
Types of Network Monitoring • Event-based alerts • Snort, Suricata, SourceFire, RSA NetWitness • Require rule sets • Provides real-time notification
Types of Network Monitoring • Headers or full packets • Helps to identify scope of data theft • Capture actions done with interactive shells • Closely monitor malware communicating with remote sites
Types of Network Monitoring • High-level statistics showing type and number of packets • Can reveal interesting information on activities that are not otherwise detectable
Event-Based Alert Monitoring • Most common type • Based on rules or thresholds • Events are generated by Network Intrusion Detection Systems (NIDS) • Or by software that monitors traffic patterns and flows • Standard tools: Snort and Suricata
Indicators (or Signatures) • Matched against traffic observed by the network sensor • Simple indicators • Such as IP address + port • "Cheap" (small load on sensor) • Complex indicators • Session reconstruction or string matching • Can burden the sensor so much it drops packets
Example Snort Rule • This rule detects SSH Brute Force attacks • Depth: how many bytes of packet to read • Links Ch 9a, 9b
alert_fast • Put this in Snort configuration file • output alert_fast alerts.txt • Simplest output module for Snort • Puts text into a file
Detect Fake SSL Certificate • Detects a specific fake certificate used by an APT group identified by Mandiant's in 2003 • Written by Emerging Threats • Matches serial number and Issuer string
Header and Full Packet Logging • Two distinct purposes • To help IR team generate signatures, monitor activity, or identify stolen data • Collect evidence for an administrative or legal matter • Consider whether to treat packet captures as evidence and generate a chain of custody
Thoroughness • IDS systems can retain the full session that generated an alert • But for targeted collection against specific subjects, use tcpdump or Wireshark
tcpdump • Complete packet capture of an HTTP request • Done with "tcpdump -X" • Limiting capture to 64 bytes captures only the headers (called "trap and trace" by law enforcement)
Statistical Monitoring • Cisco NetFlow • Number of packets & bytes in each "flow" (session)
Statistical Monitoring Commercial visualization products available from Fluke, HP, Solarwinds, and IBM Link Ch 9c
flow-tools and argus • Open-source • Convert pcap file (from tcpdump) to Argus format • Graph all packets > 68 bytes from server1 by port number
CNIT 152: 9 Network Evidence
CNIT 152: 9 Network Evidence
CNIT 152: 9 Network Evidence
Setting Up a Network Monitoring System
Simple Method • Deploy laptops or 1U servers with hardware network taps • Snort + tcpdump works • Best if you are setting up monitoring after an incident is detected--fast & easy
IDS Limitations • IDS platforms cannot reliably perform both intrusion detection and network surveillance simultaneously • If you set an IDS to capture full-content, its effectiveness as a sensor will diminish
Effective Network Surveillance
Hardware • Difficult to collect and store every packet traversing high-speed links • Recommended: • 1U servers from large manufacturers • Linux-based network monitoring distributions • Linux now outperforms FreeBSD • For best performance, use NTOP's PF_RING network socket, not the default AF_PACKET interface
Before an Incident • If your organization plans ahead • Commercial solutions that combine Snort-style alerting wth storage • Solera Network's DeepSea appliance • RSA's NetWitness platform
Security Onion • Free Linux distribution, with kernel patched installed (securityonion.net) • Includes analysis tools
Deploying the Network Sensor
Major Network Changes • May facilitate network surveillance • Ex: route all company locations through a single Internet connection with MPLS (Multiprotocol Label Switching), not a separate ISP for each office
Secure Sensor Deployment • Place network sensor in a locked room, to maintain chain of custody • Patch the OS, keep it up to date • Protect it from unauthorized access • Document everything • Review logs • Use Tripwire to ensure integrity of OS
Evaluating Your Network Monitor • Is it receiving the traffic you want to monitor? • Is the hardware responsive enough to achieve your goals? • Create signatures to detect test traffic and test your monitor • Such as a nonexistent URL • Performance metrics in logs will tell you if the sensor is dropping packets
Network Data Analysis
General Principles • Wireshark is excellent • Especially with custom decoders, written in Lua or C • Don't hunt through large packet captures looking for something new • Limit the scope • Use targeted queries that follow your leads and answer investigative questions
Data Theft Scenario • On Dec. 3, 2013, your investigation starts • Two days ago, an attacker accessed a user's desktop system • Ran rar.exe and ftp.exe once each • You have complete packet capture data
Prefetch • Shows exact date and time ftp.exe was executed • Dec. 1, 2013 at 00:57 UTC • Interviews tell you that RAR and FTP are not used normally on that workstation
PCAP File • 73 FTP sessions on the date in question • 2 are active during the time of interest • Download PCAP files from link Ch 9e
• Statistics, Conversations, TCP tab • Select conversation, Follow Stream
Stream 0: FTP (Port 21) • Control traffic
Stream 1: FTP-Data (Port 20) • A RAR file being transferred • Show data as "Raw" • Save the file as file.rar with "Save as"
edi-source.bin RAR • From second pcap file
Password • The RARs are password-protected • We can see the names of files and folders, but not extract them • A forensic examiner could search for command lines using RAR.exe on the system, which might contain the password • Password cracking tools might help, but they are slow
Is the Process Automated? • Look for typographical errors • Look at timing between steps of the attack • Timing below indicates a human user
File from First Session • pwdump hacking tool, steals password hashes
Webshell Reconnaissance Scenario • IDS detects a port scan coming from your DMZ • From an Apache & MySQL server, on Windows, at 203.0.113.101 • Interviews: no authorized port scan was run at that time • Login history shows no user logged in to the server at that time
Apache Server Logs • Large number of requests at the time of interest • From an external IP address you don't recognize • Many different pages requested • Then many requests of the "/apps/login.php" page
PHP Shell • Many POST requests to "/apps/login.php" • Then GET requests to "/tmpbkxcn.php" • Containing strings such as • cmd=netstat • cmd=tasklist
Wireshark • Data is encrypted with HTTPS (SSL)
SSL Encryption • New versions of TLS have Forward Secrecy • A different key for each session, using a "session master secret" • Older versions of TLS • All data can be decrypted with the RSA private key on the server
Importing the Key • In Wirehark • Wireshark, Preferences, Protocols, SSL • In "RSA keys list" line, click Edit
• "Decrypted SSL data" tab appears at bottom • User-Agent: sqlmap (a common hacking tool)
Exporting Decrypted Data • File, Export PDUs to File, OSI Layer 7 • Produces decrypted HTTP packets
Decrypted Data
PHP Shell Upload • From second PCAP file
Commands
NetWitness Investigator • Sorts traffic by protocol • 32-bit version seems to be gone
Collect Logs Generated from Network Events
Examples
Examples
Network-Based Logs • Server-based logs are files on the individual systems • May be altered or deleted by the attacker • Network-based logs may be more reliable • Especially if network devices are physically and electronically secured
Log Aggregation • Log aggregation is difficult because: • Logs are in different formats • Originate from different operating systems • May require special software to access and read • May have inaccurate timestamps
CNIT 152: 9 Network Evidence

More Related Content

CNIT 152: 9 Network Evidence

  • 1. CNIT 152: Incident Response 9 Network Evidence Updated 10-8-18
  • 2. The Case for Network Monitoring
  • 3. Types of Network Monitoring
  • 4. Types of Network Monitoring • Event-based alerts • Snort, Suricata, SourceFire, RSA NetWitness • Require rule sets • Provides real-time notification
  • 5. Types of Network Monitoring • Headers or full packets • Helps to identify scope of data theft • Capture actions done with interactive shells • Closely monitor malware communicating with remote sites
  • 6. Types of Network Monitoring • High-level statistics showing type and number of packets • Can reveal interesting information on activities that are not otherwise detectable
  • 7. Event-Based Alert Monitoring • Most common type • Based on rules or thresholds • Events are generated by Network Intrusion Detection Systems (NIDS) • Or by software that monitors traffic patterns and flows • Standard tools: Snort and Suricata
  • 8. Indicators (or Signatures) • Matched against traffic observed by the network sensor • Simple indicators • Such as IP address + port • "Cheap" (small load on sensor) • Complex indicators • Session reconstruction or string matching • Can burden the sensor so much it drops packets
  • 9. Example Snort Rule • This rule detects SSH Brute Force attacks • Depth: how many bytes of packet to read • Links Ch 9a, 9b
  • 10. alert_fast • Put this in Snort configuration file • output alert_fast alerts.txt • Simplest output module for Snort • Puts text into a file
  • 11. Detect Fake SSL Certificate • Detects a specific fake certificate used by an APT group identified by Mandiant's in 2003 • Written by Emerging Threats • Matches serial number and Issuer string
  • 12. Header and Full Packet Logging • Two distinct purposes • To help IR team generate signatures, monitor activity, or identify stolen data • Collect evidence for an administrative or legal matter • Consider whether to treat packet captures as evidence and generate a chain of custody
  • 13. Thoroughness • IDS systems can retain the full session that generated an alert • But for targeted collection against specific subjects, use tcpdump or Wireshark
  • 14. tcpdump • Complete packet capture of an HTTP request • Done with "tcpdump -X" • Limiting capture to 64 bytes captures only the headers (called "trap and trace" by law enforcement)
  • 15. Statistical Monitoring • Cisco NetFlow • Number of packets & bytes in each "flow" (session)
  • 17. flow-tools and argus • Open-source • Convert pcap file (from tcpdump) to Argus format • Graph all packets > 68 bytes from server1 by port number
  • 21. Setting Up a Network Monitoring System
  • 22. Simple Method • Deploy laptops or 1U servers with hardware network taps • Snort + tcpdump works • Best if you are setting up monitoring after an incident is detected--fast & easy
  • 23. IDS Limitations • IDS platforms cannot reliably perform both intrusion detection and network surveillance simultaneously • If you set an IDS to capture full-content, its effectiveness as a sensor will diminish
  • 25. Hardware • Difficult to collect and store every packet traversing high-speed links • Recommended: • 1U servers from large manufacturers • Linux-based network monitoring distributions • Linux now outperforms FreeBSD • For best performance, use NTOP's PF_RING network socket, not the default AF_PACKET interface
  • 26. Before an Incident • If your organization plans ahead • Commercial solutions that combine Snort-style alerting wth storage • Solera Network's DeepSea appliance • RSA's NetWitness platform
  • 27. Security Onion • Free Linux distribution, with kernel patched installed (securityonion.net) • Includes analysis tools
  • 29. Major Network Changes • May facilitate network surveillance • Ex: route all company locations through a single Internet connection with MPLS (Multiprotocol Label Switching), not a separate ISP for each office
  • 30. Secure Sensor Deployment • Place network sensor in a locked room, to maintain chain of custody • Patch the OS, keep it up to date • Protect it from unauthorized access • Document everything • Review logs • Use Tripwire to ensure integrity of OS
  • 31. Evaluating Your Network Monitor • Is it receiving the traffic you want to monitor? • Is the hardware responsive enough to achieve your goals? • Create signatures to detect test traffic and test your monitor • Such as a nonexistent URL • Performance metrics in logs will tell you if the sensor is dropping packets
  • 33. General Principles • Wireshark is excellent • Especially with custom decoders, written in Lua or C • Don't hunt through large packet captures looking for something new • Limit the scope • Use targeted queries that follow your leads and answer investigative questions
  • 34. Data Theft Scenario • On Dec. 3, 2013, your investigation starts • Two days ago, an attacker accessed a user's desktop system • Ran rar.exe and ftp.exe once each • You have complete packet capture data
  • 35. Prefetch • Shows exact date and time ftp.exe was executed • Dec. 1, 2013 at 00:57 UTC • Interviews tell you that RAR and FTP are not used normally on that workstation
  • 36. PCAP File • 73 FTP sessions on the date in question • 2 are active during the time of interest • Download PCAP files from link Ch 9e
  • 37. • Statistics, Conversations, TCP tab • Select conversation, Follow Stream
  • 38. Stream 0: FTP (Port 21) • Control traffic
  • 39. Stream 1: FTP-Data (Port 20) • A RAR file being transferred • Show data as "Raw" • Save the file as file.rar with "Save as"
  • 41. Password • The RARs are password-protected • We can see the names of files and folders, but not extract them • A forensic examiner could search for command lines using RAR.exe on the system, which might contain the password • Password cracking tools might help, but they are slow
  • 42. Is the Process Automated? • Look for typographical errors • Look at timing between steps of the attack • Timing below indicates a human user
  • 43. File from First Session • pwdump hacking tool, steals password hashes
  • 44. Webshell Reconnaissance Scenario • IDS detects a port scan coming from your DMZ • From an Apache & MySQL server, on Windows, at 203.0.113.101 • Interviews: no authorized port scan was run at that time • Login history shows no user logged in to the server at that time
  • 45. Apache Server Logs • Large number of requests at the time of interest • From an external IP address you don't recognize • Many different pages requested • Then many requests of the "/apps/login.php" page
  • 46. PHP Shell • Many POST requests to "/apps/login.php" • Then GET requests to "/tmpbkxcn.php" • Containing strings such as • cmd=netstat • cmd=tasklist
  • 47. Wireshark • Data is encrypted with HTTPS (SSL)
  • 48. SSL Encryption • New versions of TLS have Forward Secrecy • A different key for each session, using a "session master secret" • Older versions of TLS • All data can be decrypted with the RSA private key on the server
  • 49. Importing the Key • In Wirehark • Wireshark, Preferences, Protocols, SSL • In "RSA keys list" line, click Edit
  • 50. • "Decrypted SSL data" tab appears at bottom • User-Agent: sqlmap (a common hacking tool)
  • 51. Exporting Decrypted Data • File, Export PDUs to File, OSI Layer 7 • Produces decrypted HTTP packets
  • 53. PHP Shell Upload • From second PCAP file
  • 55. NetWitness Investigator • Sorts traffic by protocol • 32-bit version seems to be gone
  • 56. Collect Logs Generated from Network Events
  • 59. Network-Based Logs • Server-based logs are files on the individual systems • May be altered or deleted by the attacker • Network-based logs may be more reliable • Especially if network devices are physically and electronically secured
  • 60. Log Aggregation • Log aggregation is difficult because: • Logs are in different formats • Originate from different operating systems • May require special software to access and read • May have inaccurate timestamps