Network Forensics

Michael Sonntag Institute of Networks and Security What is it?

 Evidence taken from the “network”  In practice this means today the Internet (or LAN)  In special cases: Telecommunication networks (as long as they are not yet changed to VoIP!)  Typically not available “after the fact”  Requires suspicions and preparation in advance  Copying the communication content  At the source (=within the suspects computer): “Online search”  This could also be a webserver, e.g. if it contains illegal content  “Source” does NOT mean that this is the client/initiator of communication/…  At the destination: See some part of the traffic  Only if unavoidable or the only interesting part  Somewhere on the way of the (all?) traffic: ISP, physically tapping the wires, home routers etc.

Network Forensics 2 Problems of network forensics

 “So you have copied some Internet traffic – but how is it linked to the suspect?”  The IP addresses involved must be tied to individual persons  This might be easy (location of copying) or very hard  “When did it take place?”  Packet captures typically have only relative timestamps  But there may be lots of timestamps in the actual traffic!  As supporting evidence to some external documentation  “Is it unchanged?”  These are merely packets; their content can be changed  Although it is possible to check e.g. checksums, this is a lot of work and normally not done  Treat as any other digital evidence  Hash value + Chain of Custody; work on copies only

Network Forensics 3 Scenario

 Suspect: Mallory Malison; released from jail on bail  Suspicion of attempted corporate espionage  There is some suspicion that he may try to flee  But we currently have no hard evidence at all  Released  Soon after he disappears…  What happened forensically:  Copying all traffic outgoing from his computer  Your task: Find out all about his activities, specifically:  Any (attempted) communication with others  Including all “names” and “aliases” used (his and counterparts)  Including all content (text, files etc) if possible  Any hints to locations  All other information you can find  For our example only!

Network Forensics 4 Source

 Packet capture “scenario.pcap”  Contains the actual packet capture  Hash value (SHA256): sha256sum -b scenario.pcap f2bccff18f4966fc352d032df834c818e4da052bfd32494bd729 ff5c0c8a93f4 *scenario.pcap  Time: 21.4.2015, approx. 9:19  Created with tcpdump on a Linux system  tcpdump –ni enp0s3 -s 65535 -w scenario.pcap  Program for inspection/evaluation: Wireshark  Can be used for capturing packets, but also for displaying/investigating traces from other sources

Network Forensics 5 So brief only because activity was “condensed” General overview - and to finish the lesson in time!

 Load the capture in wireshark and get an overview  Packets: 1389; Total time: 227.53… seconds ( 4 min.)  Statistics - Summary:

Network Forensics 6 Statistics - Protocol hierarchy

 Overview on what was going on  Take care:  Numbers are not necessarily reliable  Packets can contain several/no protocols  E.g. IMAP: Server response might be “TCP” and not counted under IMAP  If not dissected as such

Network Forensics 7 Arp

 Could show us what other computers were present in the subnet (Right-click - Apply as filter - Selected)  Asking for 169.254.10.120: APIPA  Not interesting  Asking for 192.168.10.1  See later with DHCP!  Asking for 192.168.10.254  One more computer!  In this case: Default gateway of this subnet/server  Other information: MAC addresses  Can be used for identification of devices (later or when known for filtering)  08:60:6e:42:d2:4f: Client computer (=suspect)  ASUSTek Computer Inc.  08:00:27:7f:a8:b4: Default gateway/server  CADMUS COMPUTER SYSTEMS; actually: Virtualbox uses these  For MAC/OUI identification see https://regauth.standards.ieee.org/standards-ra-web/pub/view.html#registries

Network Forensics 8 DHCP (“Bootstrap Protocol”)

 Discover, Offer, Request and Ack  This computer received a new IP address  It has presumably not been in this subnet before  But: Discover contains option 50: “Request IP address”  So it has been in this subnet (or one very similar to it!) and it had then (=the last time) 192.168.10.1  Add ICMP to it:  (bootp and udp and ip and eth and frame) or icmp  Server tests with Ping whether the requested (or selected by him) address is free  Hostname (Request option 12): “malmals-laptop”  Some hint that it is indeed “Mallory Malisons” Laptop  Requests lots of things; and gets them (Offer/Ack)  DNS: 192.168.10.254; Network: 192.168.10.254/24  Domain name is “provider.com”

Network Forensics 9 DNS

 Take care: DNS alone is often misleading/strange  DNS is almost always the first step for something else  Whatever this is, it will be invisible if showing DNS only!  Querying for its own name: “malmals-laptop”  Active Directory: _ldap._tcp.dc._msdcs.provider.com  Win. checking network connectivity: dns.msftncsi.com  “Network Connectivity Status Indicator”  Autoconfiguration: wpad.provider.com, wpad  404 hijack identification: engcqdycrtvlgej.provider.com  En-us.appex-rf.msn.com  Response: redirect to Akamai webhosting  foodanddrink.tile.appex.bing.com; finance.*, weather.*  Windows 8.1 tile live data

Network Forensics 10 DNS

 irc.gamesurge.com: See later (IRC)!  r00t.cf: See later (NTP)!  mail.provider.com: See later (SMTP)!  Thunderbird welcome page: live.mozillamessaging.com, www.mozilla.org  ocsp.digicert.com: Certificate revocation check for this connection, which uses https  mozorg.cdn.mozilla.net: Welcome page content

Network Forensics 11 Netbios, WS-Discovery

 Again we get the computer name: MALMALS-LAPTOP  But now we also get the “normal” Domain/Workgroup the computer belongs to  In this case: Workgroup “WORKGROUP” (=standard value)  Web Services Discovery Protocol (UDP “data” protocol)  Discovering other devices via a multicast (239.255.255.250)  Works through SOAP on port 3702  E.g. network printers, “people near me”  Provides a new ID (unclear how permanent!)

Network Forensics 12 SSDP

 Simple Service Discovery Protocol; SSDP  Identified as HTTP  Discovering other devices via a multicast (239.255.255.250)  Works through HTTP-formed-content on port 1900  Basis for UPnP  Interesting: No answers; no one else is there or they are (specifically!) configured to not use these protocols  UPnP is typically switched on by default in consumer devices

Network Forensics 13 NTP

 We have two time synchronizations (packets 163-166)  (Client + Server ) * 2 ☺  Interesting: Windows is typically configured with a Microsoft time server, but here 188.40.92.202 is used  What’s this? Check it manually!  Or better: Switch back to “full view” (“Clear”) and see the DNS request immediately before asking for “r00t.cf”  Note: Filtering in wireshark e.g. “ip.addr==188.40.92.202” will not be useful, as this is message content in DNS, not part of the packet metadata!  The DNS server does have a completely different IP address  Note: “frame contains "188.40.92.202"” doesn’t work either, as this would only match string content!  But: “frame contains "\xbc\x28\x5c\xca"” works! (hex representation of IP address; but you might also want to check for other byte orders too!)

Network Forensics 14 OCSP

 Certificate validation is present  So obviously some secure connection was tried, successfully initiated, and then the certificate was checked for validity  Which one? We don’t know from the request! It only contains hashes of the issuer, the key and the serial number of the certificate  Hashes are relatively useless…  If we had some concrete suspicion, we could check it!  frame contains "\x03\x37\xb9\x28" (start of the serial number of the certificate) leads to packet 342; following this TCP stream we find it stems from a https connection to 63.245.215.20  Which immediately before has a DNS response for this IP with the name mozorg.dynect.mozilla.net  It is the parent certificate of the certificate www.mozilla.org (packet 344)  Issued by DigiCert High Assurance EV Root CA  So now we know from what connection it stems and what certificate “initiated” the request

Network Forensics 15 SMTP

 We see two sessions (tcp.port==25 and tcp.flags.syn==1)  Starting at packets 677 and 1067  Session 1: 677  Plain authentication (see later)  Message from “[email protected]”  Message to “[email protected]”  Simple text content + attachment  The text we can easily read/copy out: “Follow TCP stream” + mark + Ctrl-C  But the attachment? We can copy it out, but it is “encrypted”!  Filename: “Meeting.docx”, Transfer-encoding: base64  So copy text, save as file, decode from base64 (d=decode, i=ignore garbage  the linebreaks), view it  base64 –d –i attachment.txt >Recovered.docx  Use e.g. Cygwin or a Linux system

Network Forensics 16 Message 1: Text

 Hi Trudy!

I urgently need the data you "obtained" from ACME; my client is getting restless!!

Meet me at the point shown in teh attachment!

Only then our common future will be sure!

See you soon, hottie

Mallory

 Doesn’t look too good for our suspect…

Network Forensics 17 Message 1: Attachment

 Time + Location  Nice!

Network Forensics 18 “Carving” image from document

 Extracting the image might be helpful:  We can compare it easily to other images on a computer  We can calculate a hash value to search for it  How to do it: Trivial, because it is a docx!  This means, it is actually a ZIP file with XML (and other) content  Make copy, rename to ZIP, extract, look for image  Look in subdirectory “word/media”  image1.png

Note: If you are observant you can identify a mistake of the person creating the scenario in this image!

Network Forensics 19 Additional data from the document

 We can also investigate the document metadata  Through Office or as text  File: docProps\core.xml    Mallory Malison    Mallory Malison  4  2015-04- 15T07:41:00Z  2015-04- 15T07:44:00Z

Network Forensics 20 Plain authentication

 This is a not-so-secure version of authentication  See RFC 4616 for the description  “The client presents the authorization identity (identity to act as), followed by a NUL (U+0000) character, followed by the authentication identity (identity whose password will be used), followed by a NUL (U+0000) character, followed by the clear-text password.“  Strict recommendation: Use only with outer encryption, e.g. TLS  Big advantage: Authenticate as user 1 but act (=impersonate) as user 2 (optional); e.g. Administrator can act as normal user  Big problem: Lack of encryption or other security  Single message from client to server  So no protection against replay, modification, sniffing etc.  In practice (SMTP) base64 encoding is used in addition  AUTH PLAIN AGphbWVzcG9uZAA1dXAzcjVjdThh  Content decoded: AUTH PLAIN \0jamespond\05up3r5cu8a  Now we know his username and his mail password!

Network Forensics 21 Second mail message sent

 Similar to first message (PLAIN LOGIN), but no attachment present  Recipient: [email protected]  Text:  My beloved Carol! Unfortunately we will not be able to meet tomorrow evening for the candlelight dinner we planned - I have to leave town urgently. I'll make up for it when we meet in Venice! Always in love with you, Mallory P.S. Don't forget about teh data I asked you - otherwise I'll never be able to prove the wrong the company you're working for did to me.  Notice a common mistake: “the”  “teh“  Also: Hint that he is going to disappear intentionally  But: No date, and only “venice”

Network Forensics 22 IMAP

 Retrieving messages: 2 conversations  tcp.port==143 and tcp.flags.syn==1  Again we get a server header (rather useless here)  But no content: STARTTLS is used  We do get the certificate of the server, which is a self-signed one (and therefore useless)  And the amount of data:  Session 1: Most going to server (large; shown in red - outgoing)  Session 2: Approx. the same content; but this time coming from server (shown in blue - incoming)  See also: “Interleaving”  Might give an idea what was happening on a very high level

Network Forensics 23 IMAP + SMTP

 IMAP (181@103 sec – 339@104 sec)  Start connection, check for new mails  Long IMAP (418@114 sec – 657@117 sec)  Retrieve long E-Mail  SMTP Send msg with attachm. (677@131 sec – 954@ 131 sec) Long IMAP (959@131 sec - 1045@134 sec)  Send mail and copy it into “Sent” folder  IMAP (1053@145 sec - 1063@145 sec)  New messages/changes?  SMTP send short (1067@156 sec – 1093@156 sec)  Short IMAP (1095@156 sec – 1136@160 sec)  Send mail and copy it into “Sent” folder  IMAP (1156@179 sec – 1186@180 sec) ▪ New messages/changes? Quit

Network Forensics 24 SSH

 An encrypted communication also took place  Client: SSH-2.0-PuTTY_Release_0.64  Server: SSH-2.0-OpenSSH_4.3  Destination: 62.218.130.121  Could be used to validate identity of counterpart  What is actually being used (packet 1196): aes256-ctr, no compression, HMAC-SHA2-256  AES 256 Bit Counter mode, with SHA2 (256 Bit) in HMAC mode for integrity checks  Forget about breaking it…  We can calculate an estimate of the data transferred: 550102 bytes transferred (both directions!)  Packets 1230-1360 are in close sequence; before and after is a time-gap  Probably one transfer of approx. 520 kB outward  Actual file size: 510 kB

Network Forensics 25 IRC (TCP only, no subheading!)

 Packets 156-158 are “strange”  SYN packets without anything else  At 71, 74, and 80 seconds  So nothing else was going on at that moment!  What is port “6667”? IRC (Internet Relay Chat)  Also used by many Trojans!  Either the suspect has a trojan, or he (or his computer) tried to connect to an IRC server  Which one? See DNS request (packets 154-155)  irc.gamesurge.net  Probably not a trojan control server  Is it up? Why did the communication not succeed? We don’t know, but it was not for the suspect not trying!  So we might try to find some archived chats from there or identify the suspects user profile on that server

Network Forensics 26 HTTP

 Several HTTP connections occurred, but none of them look interesting for this investigation  Related to Windows 8.x live tiles  So the suspect was using Windows (see DNS!) and version 8 at least (live tiles!)  http://en-US.appex-rf.msn.com/cgtile/v1/en-US/Sports/Today.xml?cgversion=v6  http://foodanddrink.tile.appex.bing.com/api/feed/?view- name=data&name=livetile&market=en-US&version=2_0&format=xml  http://en-US.appex-rf.msn.com/cgtile/v1/en-US/News/Today.xml  http://en-US.appex-rf.msn.com/cgtile/v1/en- US/HealthAndFitness/Home.xml?cgversion=v6  http://finance.services.appex.bing.com/Market.svc/AppTilev2?symbols=& contentType=-1&TileType=0&locale=en-US  http://weather.tile.appex.bing.com/WeatherService.svc/PreInstallLiveTile? lang=en-US®ion=US&appid=C9…36&FORM=APXWEA  Might show some interests of the suspect or his location  Personalization by Microsoft or manual configuration

Network Forensics 27 Full text search approach

 We can also try a fulltext search for any information  Directly within the network dump, e.g. using ngrep  Attention: This is often not in the normal repositories. You might have to install/enable additional ones (CentOS: EPEL) or compile it manually  For this we need search words, but here we have few:  “Mallory”, “Malison”  Second step (after we found something): The E-Mail addresses  ngrep: Lots of parameters ngrep match_expression filter_expression  -i: Ignore case in regular expression  -: Just packet header (+payload if relevant)  -v: Inverted match (show what doesn’t match the expression)  -t: Print timestamp  -S: Limit length of packet to check for the expression  -I: Do not read from interface but rather from a dump file  -O: Output not to console but a dump file

Network Forensics 28 http://ngrep.sourceforge.net/ Full text search

 ngrep -t -q -I scenario.pcap "Mallory"

 input: scenario.pcap  match: Mallory

 T 2015/04/21 09:21:55.216949 192.168.10.1:49174 -> 192.168.10.254:25 [AP]  Message-ID: <[email protected]>..Date: Tue, 21 Apr 2015 09:21:54 +0200..From: Mallory Malison ..User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0..MIME-Version: 1.0..To: [email protected]: Seeing you soon..Content-Type: multipart/mixed;.. boundary="------020006080700010304080400"....This is a multi-part message in MIME format...------020006080700010304080400..Content-Type: text/plain; charset=utf-8; format=flowed..Content- Transfer-Encoding: 7bit....Hi Trudy!....I urgently need the data you "obtained" from ACME; my client is getting..restless!!....Meet me at the point shown in the attachment!....Only then our common future will be sure!....See you soon, hottie.. Mallory....------020006080700010304080400..Content-Type: application/octet-stream;.. name="Meeting.docx"..Content-Transfer-Encoding: base64..Content-Disposition: attachment;..filename="Meeting.docx"....UEsDBBQABgAIAAAAIQCtsT5y2QEAANgDAAAQAAgBZ G9jUHJvcHMvYXBwLnhtbCCiBAEooAAB..AAAAAA  Note: Unprintable characters are replaced by a dot

Network Forensics 29 Full text search  Second match

 T 2015/04/21 09:22:19.978928 192.168.10.1:49175 -> 192.168.10.254:25 [AP]  Message-ID: <[email protected]>..Date: Tue, 21 Apr 2015 09:22:19 +0200..From: Mallory Malison ..User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0..MIME-Version: 1.0..To: [email protected]: Dinner postponement..Content-Type: text/plain; charset=utf-8; format=flowed..Content-Transfer-Encoding: 7bit....My beloved Carol!....Unfortunately we will not be able to meet tomorrow evening for the ..candlelight dinner we planned - I have to leave town urgently.....I'll make up for it when we meet in Venice!....Always in love with you,.. Mallory....P.S. Don't forget about teh data I asked you - otherwise I'll never be ..able to prove the wrong the company you're working for did to me...  What did we find? The two E-Mails he sent!  Which we already know about…  But if we had started like this, we would know where to look  Searching for “Malison”: Almost same result  Mail header: From: Mallory Malison  “jamespond@” 4 results: 2*envelope + 2*mail content  Other E-Mails: 2 results each (envelope+content)

Network Forensics 30 Timeline (1)

 21.4.2015 9:19:43: Start of capture  9:19:47: DHCP request from “malmals-laptop”  9:19:48: IP address 192.168.10.1 assigned  9:19:49: Workgroup join/domain browser/AD search  9:20:42: Web requests for tile content  9:20:55: IRC connection tries  9:21:14: Time synchronisation with r00t.cf  9:21:26: IMAP starts; download/display of large mail  9:21:55: First SMTP session  Mail sent to [email protected]  Contains an attachment  9:21:55: Long IMAP session  Probably copying the mail sent to the “Sent” folder

Network Forensics 31 Timeline (2)

 9:22:19: Second SMTP message  Mail sent to [email protected]  9:22:20: IMAP session  Probably copying the mail sent to the “Sent” folder  9:22:58: SSH session begins  Large outgoing data, little incoming (=“upload”)  9:23:17: SSH session ends  21.4.2015 9:23:31: Last message recorded; end of dump

Network Forensics 32 Summary

 We found:  Some info on the computer used  Previous IP, uncommon timeserver  Two mail messages sent  Recipient and sender E-Mail address  Full text  Attachment with map (=location) and time for meeting  Username and password for mail account  Hints on the general usage of IRC with a specific server  SSH large upload; probably SFTP

Network Forensics 33 THANK YOU FOR https://www.ins.jku.at YOUR ATTENTION!

Michael Sonntag [email protected] +43 (732) 2468 - 4137 JOHANNES KEPLER nd UNIVERSITÄT LINZ S3 235 (Science park 3, 2 floor) Altenberger Straße 69 4040 Linz, Österreich www.jku.at