2023-02-09 21:31:25 +01:00
|
|
|
# Wireshark
|
|
|
|
|
2024-06-05 18:29:27 +02:00
|
|
|
## Information about Pcap Files
|
|
|
|
|
|
|
|
Get information about a given PCAP file in the following way.
|
|
|
|
|
|
|
|
```sh
|
|
|
|
capinfos example.pcap
|
|
|
|
```
|
|
|
|
|
|
|
|
Show verbose package information and bytes inside the package.
|
|
|
|
|
|
|
|
```sh
|
|
|
|
tshark -r example.pcapng -V -x
|
|
|
|
```
|
|
|
|
|
|
|
|
Autostop `-a` and ringbuffer `-b` arguments may be set to stop or split files
|
|
|
|
at defined duration `duration:10`, sizes `filesize:100`, and count of files
|
|
|
|
`files:5`.
|
|
|
|
|
2024-06-18 22:26:21 +02:00
|
|
|
Use `-z help` to see options of possible statistics, use `-q` to suppress
|
|
|
|
packet details.
|
|
|
|
|
|
|
|
## Find Credentials
|
|
|
|
|
|
|
|
Tshark can list all found credentials via the following command
|
|
|
|
|
|
|
|
```sh
|
|
|
|
tshark -r file.pcap -z credentials -q
|
|
|
|
```
|
|
|
|
|
2023-02-09 21:31:25 +01:00
|
|
|
## Extracting USB Keystrokes
|
|
|
|
|
2024-06-05 18:29:27 +02:00
|
|
|
Data between USB devices and the host can be filtered via tshark in order to
|
|
|
|
display just the payload, e.g. keystrokes in the following way
|
|
|
|
|
2023-02-09 21:31:25 +01:00
|
|
|
```sh
|
|
|
|
tshark -r keystrokes.pcapng -Y "usb.transfer_type==0x01 and frame.len==35 and! (usb.capdata == 00:00:00:00:00:00:00:00)" -T fields -e usbhid.data > output.txt
|
|
|
|
```
|
|
|
|
|
2024-06-18 22:26:21 +02:00
|
|
|
A lookup table is needed to [convert the USBHID data to ASCII
|
|
|
|
values](https://gist.github.com/ImAnEnabler/091a9e1ee2d6a0805408e009e2f4a2b5)
|
2024-06-05 18:29:27 +02:00
|
|
|
|
|
|
|
```sh
|
2023-02-09 21:31:25 +01:00
|
|
|
python keystrokedecoder.py output.txt
|
|
|
|
```
|
|
|
|
|
2023-04-17 22:49:17 +02:00
|
|
|
## Extracting Payload sent in DNS Request
|
|
|
|
|
2024-06-05 18:29:27 +02:00
|
|
|
Search for the DNS requests containing the specific top level domain.
|
|
|
|
|
2023-04-17 22:49:17 +02:00
|
|
|
```sh
|
|
|
|
tshark -r capture.pcapng -Y 'dns && ip.dst==167.71.211.113 && (dns contains xyz)' -T fields -e dns.qry.name | awk -F '.' '{print $1}' | uniq > dns.out
|
|
|
|
```
|
2024-03-03 20:15:35 +01:00
|
|
|
|
|
|
|
## NTLMv2 hash Reconstruction via SMBv2
|
|
|
|
|
|
|
|
Session setup of SMBv2 leaves enough information to reconstruct the NTLMv2 hash.
|
|
|
|
Take a look at the second and third packets of the initialization, namely
|
|
|
|
`Session Setup Response, Error: STATUS_MORE_PROCESSING_REQUIRED, NTLMSSP_CHALLENGE`
|
|
|
|
and `Session Setup Request, NTLMSSP_AUTH, User: <DOMAIN\USERNAME>`.
|
|
|
|
|
|
|
|
The scheme of an NTLMv2 hash is the following.
|
|
|
|
|
|
|
|
```
|
|
|
|
[User name]::[Domain name]:[NTLM Server Challenge]:[NTProofStr]:[Rest of NTLMv2 Response]
|
|
|
|
```
|
|
|
|
|
|
|
|
The `NTLM Server Challenge` can be found inside the `Security Blob` of the
|
|
|
|
request from the server.
|
|
|
|
`User name`, `Domain name` and `NTLMv2 Response` can be found inside the
|
|
|
|
`Security Blob` inside the response sent by the client. `NTProofStr` is the
|
2024-06-05 18:29:27 +02:00
|
|
|
first part of the `NTLM Response`. Set a `:` between `NTProofStr` and the rest
|
|
|
|
of the `NTLMv2 Response`.
|