Network Forensics – All 30 Questions (Easy English)

OSCAR has five steps:

1. OObtain Information: Collect basic details about the attack, such as the affected server, IP address, and time.
2. SStrategize: Make a plan. Decide which evidence to check first.
3. CCollect Evidence: Collect PCAP files, firewall logs, web logs, and NetFlow records.
4. AAnalyze: Check the evidence to identify suspicious connections and activities.
5. RReport: Write what happened, when it happened, and what evidence supports your findings.

Start with NetFlow records because they quickly show which IP addresses communicated, when they communicated, and how much data was transferred.

This helps us find suspicious traffic before examining the large 6 GB PCAP file.

• Check that all logs use the same time zone.
• Find events between 02:00 and 03:00.
• Match the source and destination IP addresses.
• Use NetFlow to identify connections, firewall logs to check allowed or blocked traffic, and PCAP to examine packets.
• Arrange the events in time order.

1. Some packets or log records may be missing.
2. Encrypted traffic may hide important information.

tcpdump -r original.pcap -w filtered.pcap 'host 10.10.10.25 and tcp port 443'

This command reads the original PCAP and saves only TCP port 443 traffic involving 10.10.10.25.

Example Wireshark display filter:

ip.addr == 10.10.10.25 && tcp.port == 443

Open Wireshark and select:

Statistics → Conversations → TCP

Sort the conversations by the Bytes column. Connections with unusually high byte counts should be examined.

• It makes analysis faster.
• It removes unrelated traffic.
• It helps investigators focus on important packets.

Risk: Important evidence may be missed if the filter is too strict.

Use SPAN and NetFlow during the ongoing attack.

SPAN provides packet details, and NetFlow provides a quick traffic summary. Both can often be used without stopping the network.

A TAP can be installed later if a suitable maintenance window is available.

• Dropped packets may hide important attack steps.
• Asymmetric routing means traffic in one direction may take a different route. The sensor might only capture one side of the connection.

Both problems can lead to an incomplete conclusion.

1. Calculate a SHA-256 hash to check that the evidence has not changed.
2. Maintain a chain of custody recording who collected, accessed, or transferred the evidence.

1. Client sends SYN to start a TCP connection.
2. Server replies with SYN-ACK.
3. Client sends ACK. The TCP connection is established.
4. Client requests /admin.
5. Server responds with 401.
6. Client sends a login request.
7. Server responds with 302.

The first three packets form the TCP three-way handshake. Its purpose is to establish a connection and confirm that both sides can communicate.

• 401 Unauthorized: Authentication is required or the request did not provide valid authentication.
• 302 Found: The server tells the client to visit another URL.

The 302 response after login might indicate a redirect to a dashboard, but it does not prove that login was successful.

It is a Wireshark feature that shows the communication between a client and server in one place.

For unencrypted HTTP, it can show requests, responses, headers, and available content.

1. Authentication or application logs showing a successful login.
2. Session records and later requests showing access to a protected page.

The traffic suggests a TCP SYN flood attack.

The three sources send:

A SYN flood sends many connection requests without completing the TCP handshake. This can fill the server's connection queue and affect real users.

• Server sends 28,000 SYN-ACK packets.
• Clients send only 600 final ACK packets.

Very few handshakes appear to be completed compared with the number started.

This supports the SYN flood theory, although some packets may be missing or repeated.

1. Check whether many TCP connections remain half-open without a final ACK.
2. Check whether SYN packets are repeated rapidly without normal data communication.

tcp.flags.syn == 1 && tcp.flags.ack == 0

This shows SYN packets that are not SYN-ACK responses.

IP Protocol 6 means TCP.

Formula:

• PSH (Push): Requests that the receiving TCP stack pass available data to the application promptly.
• ACK (Acknowledgment): Confirms receipt of TCP data up to an acknowledgment number.

These flags do not prove that the application data is safe, malicious, or successfully processed.

TTL decreases as a packet passes through routers.

However, different systems can start with different TTL values, such as 64, 128, or 255.

Because we do not know the original TTL, a value of 58 cannot tell us the exact number of routers crossed.

1. TCP Sequence Number: Helps identify repeated or retransmitted data.
2. IP Fragment Offset / Flags: Helps identify packets split into smaller fragments.
3. TCP Flags: Unusual SYN, RST, or FIN patterns can indicate scanning or connection problems.

ICMP is normally used for network testing, such as ping.

Repeated Echo Requests with around 900 bytes of changing data may suggest that someone is using ICMP to secretly carry information.

This is called an ICMP covert channel.

Use:

icmp

Check:

• Identifier: Helps match related ICMP messages.
• Sequence number: Shows the order of requests.
• Packet size: Helps identify unusually large requests.
• Payload: Check whether the data contains readable text, repeated patterns, or changing encoded content.

1. Check whether an approved network monitoring tool is generating the traffic.
2. Check the endpoint process, packet timing, and payload patterns for unusual behavior.

No. Large ICMP packets may also be used for legitimate tests.

We need more evidence, such as the sending process and the meaning of the payload.

When a client starts a TLS connection, it sends a ClientHello message.

The message may include SNI (Server Name Indication), which tells the server which domain the client wants.

Example:

SNI: example.com

A network security device can use visible SNI information to identify a requested domain.

DPI means Deep Packet Inspection.

The device may see information such as IP addresses, ports, and an unencrypted SNI.

However, HTTPS encrypts application content, such as web requests and responses. Without decryption keys or authorized interception, DPI cannot read that content.

1. Encrypted ClientHello (ECH) can hide the actual SNI.
2. Some connections may not include a usable SNI, such as certain direct-IP connections.

• Before TLS establishment: Look for a failed handshake, an early reset, or blocked connection logs.
• After establishment: Look for an established encrypted session followed by a block, reset, or disconnection.

Check firewall and proxy logs to confirm the reason.

The same source IP contacts several different ports on the same destination.

This is a common sign of a port scan.

However, it might be an authorized security scan. The packets alone do not prove malicious intent.

1. Whether the source scans many ports or many devices quickly.
2. Whether the traffic matches an approved security scan's time, source, and target list.

If a firewall silently drops packets, the client may receive no response.

The investigator cannot say the port is closed. It may be filtered or unreachable.

Source 172.16.5.10 contacts destination 192.168.1.20 on five ports:

21, 22, 23, 80, 443

Every flow has only two packets, and all records appear within 20 seconds.

This suggests a possible port scan rather than normal application use.

SiLK is a tool used to analyze network flow records.

• Use rwfilter to select traffic from the suspicious source.
• Use rwstats to group and count records by source IP, destination IP, and destination port.
• Check the number of ports contacted and the time between connections.

This helps identify scanning behavior.

1. TCP flags, especially SYN and RST flags.
2. Flow duration and byte counts.

These details help identify short connection attempts.

NetFlow summarizes connections. It does not normally contain the actual packets or application payload.

Therefore, it cannot always prove which TCP flags or exact messages were exchanged.

Given:

• Outbound = 850 MB
• Inbound = 14 MB

Answer: Approximately 61:1

This means the workstation sends about 61 times more data than it receives.

The workstation sends a large amount of data to an external server outside normal working hours.

This may indicate data exfiltration, meaning unauthorized transfer of information.

Two possible legitimate reasons are:

1. Uploading a company backup to cloud storage.
2. Synchronizing large files with an approved service.

1. Endpoint logs to identify the application sending the data.
2. Proxy logs to identify the website or service being used.
3. File access logs to check whether sensitive files were opened before the upload.

The connection uses port 443, which commonly carries encrypted HTTPS traffic.

Even with all packets captured, the content may remain unreadable without the correct decryption keys.

1. Both servers communicate through the same switch, so the traffic does not pass through the monitored router.
2. The NetFlow sensor is monitoring the wrong interface or VLAN.
3. Flow export or collection is incomplete because of sampling, dropped records, or configuration problems.

• Unidirectional flow: Records traffic moving in one direction, such as A → B.
• Bidirectional flow: Combines both directions, A → B and B → A.

If an investigator examines only one direction, they may miss replies. Bidirectional records make it easier to see the complete exchange.

1. Compare the endpoint logs with a packet capture from the switch.
2. Check whether the collector receives records from the correct network interface.

Enable flow monitoring on internal switches or deploy sensors where internal server-to-server traffic can be seen.

This improves visibility of east-west traffic, meaning traffic between devices inside the network.

1. Read the packets from the PCAP file.
2. Group packets belonging to the same connection or flow.
3. Extract important information.
4. Export the information as IPFIX records.

Important fields include:

• Source and destination IP
• Source and destination port
• Protocol
• Start and end time
• Packet count
• Byte count

IPFIX is a standard format used to store or export network flow information.

A PCAP may contain millions of packets.

IPFIX reduces this information into flow summaries. This makes it easier to identify sources contacting many ports or devices.

1. Actual packet payloads.
2. Full packet-by-packet order and timing.
3. Detailed protocol messages and some TCP behavior.

Compare the IPFIX records with the original PCAP.

Check IP addresses, ports, timestamps, packet counts, and byte counts. Investigate any unexplained differences.

At 02:10, the source IP 45.20.10.8 makes:

• Two failed attempts for root.
• Two failed attempts for admin.
• One successful password login for admin.

This suggests a possible SSH brute-force attack, where someone repeatedly tries passwords.

The admin account needs immediate investigation because its login succeeded.

The later backup public-key login comes from a different IP and should be checked separately.

A legitimate user may enter a wrong password once or twice.

A brute-force attack may show:

• Many failures in a short time.
• Attempts against multiple accounts.
• Repeated attempts from the same IP.
• A successful login after several failures.

Example:

grep 'Failed password' /var/log/auth.log |
awk '{for(i=1;i<=NF;i++) if($i=="from") print $(i+1)}' |
sort | uniq -c | sort -nr

The command finds failed SSH logins, extracts the source IP addresses, counts them, and shows the most frequent sources first.

1. Linux audit logs or command history to check what happened after login.
2. Network or firewall logs to identify any later connections or data transfers.

The most important requests are:

• GET /admin → 403: Possible attempt to reach a restricted area.
• GET /backup.zip → 404: Possible search for a backup file.
• GET /config.php.bak → 200: A possible configuration backup file was requested.
• POST /upload → 200: A file or other data may have been submitted.

The configuration backup request and upload request need special attention.

Splunk searches and analyzes logs.

Example SPL search, assuming these fields exist:

index=web clientip="10.1.1.5"
| table _time clientip method uri_path status
| sort _time

This shows the requests from the suspicious IP in time order.

We can also count unusual HTTP status codes and search for suspicious paths.

No.

HTTP 200 OK means the server handled the request successfully at the HTTP level.

It does not prove that:

• Sensitive information was returned.
• A malicious file was saved.
• The attacker gained control.

1. The HTTP response body or application logs.
2. Server file-system logs showing whether a sensitive file was accessed or an uploaded file was saved.

The workstation 10.10.5.20 sends three large POST requests to cloud.example.net.

The requests happen every two minutes and contain about 1.5–1.72 MB each.

This may indicate repeated data uploads.

Three important signs are:

1. Timing: Requests happen regularly, every two minutes.
2. Method: POST is commonly used to send information.
3. Bytes: Each request sends a large amount of data.

Together, these signs support a possible exfiltration theory, but they do not prove it.

1. Automatic cloud backup.
2. Normal application file synchronization.

1. Endpoint logs showing which process made the requests.
2. Detailed proxy logs showing URLs, response codes, and available request information.
3. Cloud audit logs showing which account uploaded the files and what actions occurred.

The events may be connected, but we must first verify that Alice's VPN session received the IP 10.8.0.5.

We need VPN session records showing:

• Alice's VPN session ID.
• The internal IP assigned to that session.
• Connection start and end times.

This will help link the external VPN connection to the internal SSH activity.

The VPN user is alice, but the SSH user is admin.

This is worth checking because one person may be using another account.

However, administrators sometimes use separate accounts for VPN and server management. Different names do not automatically mean an attack occurred.

• Incorrect system clocks can make events appear in the wrong order.
• NAT can change the visible source IP address.
• Investigators should check clock differences and NAT mapping records before linking events.

The logs show:

• GET /../../etc/passwd → Possible path traversal attack, attempting to access a file outside the web folder.
• GET /admin → Possible attempt to access an administrative page.
• POST /login → Login attempt.
• GET /dashboard → Request to a dashboard page.

The 403 suggests the path traversal request was rejected.

The later 302 and 200 do not automatically prove that the attacker logged in or exploited the application.

1. Compare the session ID or cookie used for login and dashboard requests.
2. Check source IP addresses and timestamps.
3. Check application authentication logs to see whether that session was logged in.

1. They may not contain request and response bodies.
2. They may not show whether an application session was authenticated or what actions were completed.

AP-2 is more suspicious.

Reasons:

• Both APs use the same SSID, CampusWiFi.
• AP-1 uses WPA2-Enterprise security.
• AP-2 uses Open security, which is much weaker.
• AP-2 has a stronger signal (-35 dBm), which may attract nearby users.

This could be an evil twin attack, where an attacker creates a fake Wi-Fi network that looks like the real one.

1. Beacon frames: Show the SSID, BSSID, channel, and security settings being advertised.
2. Probe responses: Show how an AP responds when devices search for a Wi-Fi network.
3. Association frames: Help identify which AP a client attempted to join.

Look for successful association events involving AP-2's BSSID.

Also check wireless sensor logs and, where available, client or network connection records.

1. Wireless controller records showing the organization's real access points.
2. A physical wireless survey to locate and examine the suspicious AP.

The sensor captures 600 deauthentication frames in 15 seconds.

That is:

This is an unusually high rate.

A deauthentication frame tells a Wi-Fi client that its connection is being ended.

A large burst of these frames may disconnect users repeatedly, causing a Denial-of-Service (DoS) attack.

Filter:

wlan.fc.type_subtype == 0x0c

This displays 802.11 deauthentication frames.

Check:

• Source and destination MAC addresses.
• BSSID.
• Reason code.
• Time and number of frames.

MAC addresses can be spoofed, meaning a device can use another device's MAC address.

An attacker may send fake frames using the real access point's address.

1. Check whether many clients receive deauthentication frames in a very short time.
2. Compare the frames with wireless controller logs to see whether the real AP intentionally disconnected clients.

Knowing the Wi-Fi password alone may not be enough.

We normally need:

1. The correct Wi-Fi password.
2. The network name (SSID).
3. The client's four-way handshake or the required session key information.

These details help Wireshark calculate the encryption keys used by the connection.

The four-way handshake happens when a Wi-Fi client connects to a WPA2 network.

It allows the client and access point to create and confirm session encryption keys.

It is important because investigators can use its information, along with the correct password, to decrypt captured traffic.

If the capture begins after the client connects, the four-way handshake may be missing.

Without the handshake or session keys, Wireshark may not have enough information to decrypt the data.

• WPA2-Personal: Normally uses a shared Wi-Fi password.
• WPA2-Enterprise: Uses an authentication system, often with individual user accounts.

Enterprise traffic usually requires session keys or other authorized key information. Knowing a normal Wi-Fi password is not enough.

RF means Radio Frequency.

An RTL-SDR receiver can help identify:

1. Unusual signal activity on a frequency.
2. Strong interference during network problems.
3. The time and frequency range where interference happens.

This helps investigators identify possible wireless interference.

No.

Several devices may use the same frequency. Signals can also reflect from walls and other objects.

A strong signal does not identify the exact device sending it.

1. Use a directional antenna and take measurements from different locations to find the signal source.
2. Compare RF activity with Wi-Fi packet captures and wireless controller logs.

Three useful categories are:

1. Network information: Source IP, destination IP, and ports.
2. Traffic information: Packet sizes, connection times, and data amounts.
3. TLS information: Some handshake details, such as visible SNI and supported TLS versions.

Encrypted HTTP content normally remains hidden.

• Regular connections may suggest automated communication.
• An unusual destination may need investigation.
• Large outbound data transfers may suggest an upload.
• Small connections at fixed intervals may suggest malware beaconing.

These patterns are clues, not final proof.

No.

TLS provides encrypted communication, but malware can also use TLS.

A successful handshake only shows that the encrypted connection was established.

1. Endpoint security logs showing which application started the connection.
2. Proxy or DNS logs providing more information about the destination and requests.

1. Open the PCAP in Wireshark.
2. Go to Edit → Preferences → Protocols → TLS.
3. Select the (Pre)-Master-Secret log filename setting.
4. Choose the correct TLS key log file.
5. Reload or examine the traffic.

If the keys match the captured sessions, Wireshark can decrypt supported traffic.

TLS uses secret key information to create encryption keys for a session.

These keys protect the application data being transferred.

If investigators have the correct session secrets, they can use them to decrypt the captured traffic.

1. The key log does not contain the secrets for the captured connection.
2. Important handshake packets may be missing from the capture.

Without decryption, investigators mainly see traffic patterns and metadata.

With decryption, they may see:

• HTTP requests and responses.
• Requested URLs.
• Uploaded or downloaded data.
• Possible commands sent by malware.

This provides stronger evidence about what actually happened.

Some TLS connections use ephemeral key exchange, such as ECDHE.

This creates temporary session secrets that cannot be calculated from the server's RSA private key alone.

Therefore, even if investigators obtain the server private key, they may still be unable to decrypt earlier captured sessions.

Forward secrecy protects old encrypted communication.

If someone steals the server's long-term private key later, they should still be unable to decrypt earlier sessions that used secure ephemeral key exchange.

This is an important TLS security feature.

1. Collect authorized TLS session key logs from the client or server.
2. Use an authorized TLS-intercepting proxy in a controlled environment.

Different TLS versions and cipher suites use different encryption and key exchange methods.

For example, older TLS 1.2 connections using RSA key exchange may allow private-key decryption, while ECDHE sessions do not.

Checking these details helps investigators choose the correct method.

The communication path is:

1. Client connects to the interception proxy.
2. The proxy decrypts the client's HTTPS traffic.
3. The proxy creates a separate encrypted connection to the real server.
4. It forwards responses back to the client.

The proxy can examine the application traffic between the two connections.

HTTPS uses certificates to help verify server identity.

To intercept HTTPS, the client must trust the proxy's certificate authority (CA).

If the client does not trust the certificate, the connection may show a security warning or fail.

1. Certificate pinning: The application accepts only a specific certificate or key.
2. Certificate trust problems: The client refuses the proxy-generated certificate.

1. The proxy may change some traffic details, such as headers or timing. Investigators must document this.
2. Decrypted traffic may contain passwords or private information, so it must be stored securely.

The traffic suggests possible DNS tunneling.

DNS tunneling means using DNS queries and responses to secretly carry information.

Three suspicious indicators are:

1. Hundreds of DNS queries every minute.
2. Frequently changing, random-looking subdomains.
3. Repeated queries to the same parent domain, data.example.com.

• Query frequency: How many DNS requests occur per minute?
• Subdomain length: Are the subdomain names unusually long?
• Entropy: Do the names look random instead of using normal words?
• DNS responses: Are there unusual replies, repeated errors, or suspicious response data?

The given subdomain labels are short, but their changing patterns and high frequency still deserve investigation.

To show DNS traffic:

dns

To focus on the suspected domain:

dns.qry.name contains "data.example.com"

To show DNS traffic from the workstation:

dns && ip.src == 192.168.1.25

No.

Some legitimate applications also generate many changing DNS names.

We need more evidence from the endpoint, DNS responses, and any decoded data before confirming exfiltration.

Yes.

Attackers can use trusted cloud storage services to:

• Upload stolen data.
• Receive instructions.
• Exchange information with infected devices.

Therefore, a legitimate cloud provider does not automatically mean the traffic is safe.

mitmproxy is a tool used to inspect HTTP and HTTPS communication.

In an authorized environment, it can:

1. Intercept application requests.
2. Show available request and response contents after TLS interception.
3. Help identify suspicious uploads, downloads, and API activity.

TLS interception requires the proper certificate trust and may not work with all applications.

Investigators can examine:

• Which cloud account was used.
• Which API actions were performed.
• Which files or objects were uploaded or downloaded.
• The time and size of each transfer.

This helps reconstruct the communication sequence.

1. Encryption or certificate pinning may stop investigators from reading the request contents.
2. Cloud access logs alone may not identify which local application or process caused the traffic.

More evidence is needed before confirming malware command-and-control activity.

The workstation communicates at:

Each connection happens exactly 60 seconds apart.

Each sends about 200 bytes and receives about 400 bytes.

This may indicate beaconing.

Beaconing happens when malware regularly contacts an external server to check for commands or send status information.

1. Timing: Does the connection happen at fixed intervals?
2. Data size: Are similar amounts of data exchanged each time?
3. Destination and application: Is the same unusual server contacted repeatedly, and which process makes the connection?

• PCAP: Shows packet timing, size, IP addresses, and connection behavior.
• Proxy logs: May show URLs, request methods, response codes, and user agents.

Combining both provides a clearer picture of the communication.

1. Legitimate applications also check for updates or send regular health reports.
2. Timing and byte counts do not reveal what the actual messages contain.

The workstation makes a DNS query and then establishes a TLS connection.

This happens every five minutes:

The regular pattern may indicate malware command-and-control beaconing.

The endpoint security alert adds concern.

However, normal cloud synchronization or automated application checks could also explain the activity.

1. DNS logs: Show that the workstation requested api.cloud-example.net.
2. TLS metadata: Shows the connections to 203.0.113.50:443, along with connection times and data sizes.
3. Proxy logs: May reveal request URLs, methods, and response details.
4. Endpoint evidence: Helps identify the process responsible for making the connections.

Arrange these records by timestamp to determine whether the same process is responsible for the repeated communication.

Authorized decryption may reveal the real application requests and responses.

Investigators can then check whether the traffic contains:

1. Commands: Instructions being received by the workstation.
2. Synchronization: Normal updates or application data exchange.
3. Transferred data: Files or information being uploaded or downloaded.

This can help separate normal activity from possible malicious communication.

1. Endpoint evidence confirms that a malicious process is making the repeated connections.
2. Decrypted traffic shows the server sending instructions that the malicious process receives or carries out.

Together, these would provide much stronger evidence of command-and-control activity.