Sunday, June 6, 2021

Packet Captures in the Age of TLS

 Ten to fifteen years ago, a company having FPC (full packet capture) was an indicator of the seriousness of the company's information security efforts. Having trained analysts that could use those packets to analyze alerts from NSM devices was an even better indicator. 

Today, the network landscape has changed to the point of having little similarity to a decade ago. The workforce was already starting to go mobile before COVID, and the pandemic forced a large swath of workers home. Mobile devices used for work became common and the services in the cloud, prevalent. 

We started seeing diminished value in some of our traditional tools. Endpoint Detection and Response suites gave us better fidelity about what was happening on our endpoints, regardless of whether the device was sitting on the corporate network, at home, or at an airport or coffee shop. AntiVirus became less useful. Yet, it still had value as a layer of defense and was good for detecting common, prevalent threats. The fact that its effectiveness was diminished didn't mean the tool was no longer useful. 

Packet captures are similar, in that though their effectiveness has been diminished by the use of SSL encrypted traffic, especially ECDH, it still has its place in layered defense. There is still much HTTP traffic on the Internet, plain text protocols are still in use even though safer alternatives have been prevalent for years, and they're a lot of cases where an attacker will use whatever means to do call-outs back to the attacking machine that uses unencrypted traffic. But there's another reason full packet capture is useful.

Consider the scenario where a host machine just made a connection to a known malicious website. The connection was made over TLS 1.2. You have packets from the connection, but the data is encrypted. An examination of the packets shows the TCP 3 way handshake, and five additional packets. In the first packet, there is some clear text obviously part of a certificate from the destination host, followed by three very small packets between the two hosts and finally a reset packet.

We can tell from the packet capture what happened, even though the data was encrypted. The client established a session with the site, the TLS handshake took place, and the session was ended. The rest was probably spoofed by a network security monitoring device if the traffic was not simply dropped by a firewall/IPS. What we can know is that there was no data exchanged between the two hosts.

If we have a full packet capture system set up, we can validate no data was exfiltrated, and no malware was downloaded, in seconds. Still very much valuable. And if there is no FPC solution, still worth the cost and effort to implement. (See Akime, formerly Moloch). 



Tuesday, February 2, 2021

Pcaps and the Tools That Love Them Part 3

 

From here, with header diagram in hand, you should know be able to look at a packet dump and find the value you need, by counting from offset 0 to the correct field. 

Some of the things you'll want to look for (like IPv6 traffic or only ICMP traffic or a particular IP) can be done most efficiently with primitives. 

Others, like, options in the IP header, which are rare and always suspicious can be done by by checking the header length field, but since the first byte in the IP header is broken into two fields of a nibble each, how do see just the header length, and not the IP version?

The answer is bitmasking. Bitmasking is hiding the bits we don't want to see and leaving the ones we do, simply put. For example, let's take the 13th byte (offset from zero, of course) in the TCP header.


Flags     CWR ECE Urg Ack     Push Reset Syn Fin

Binary Values 8    4     2    1          8      4             2    1


We have one byte, eight bits that comprise the TCP flags that can be set. We know from our basic networking that when one host wants to talk to another host, it sends a SYN (synchronize) packet to the IP address of the receiving host on the port the protocol should be listening on. 

If the receiving host is listening on that port and ready to communicate, it sends a SYN-ACK packet back (synchronize acknowledgment). 

The sending host confirms it's received the reply and is ready to start communicating by sending an ACK packet back to the destination. This is commonly known as the TCP three way hand shake.


So in order to see all of the attempts to initiate a connection on the wire or in a packet capture, we would want to see all of the packets that only have the SYN flag set. Looking at our header of byte 13, we see that the SYN flag bit is in the second nibble (4 bits) and the next to last bit. 

The way we write a BPF is to 1. specify the header, 2. the byte, and 3. any bitmasking needed to filter out additional bits.  So to see only SYN packets we would write a BPF like this:

tcp[13] = 2 - Note this shows us packets that ONLY the SYN packet is set. 

We can also write a BPF to show any packets that the SYN flag is set, as well as any another flags. To do this, instead of checking the full value of byte 13, we just check to see if the SYN bit is set. 

We would do this with a BPF like this: tcp[13] & 0x02 != 0. Here we're simply checking to see if the SYN bit is set to 1, or turned on. Any other flags could be active or not, we're not checking for anything other than SYN. 

That would mean the value of the entire byte is 2, meaning no other bits are set, or have any value but zero.

In binary our byte would be 00000010 which equals two.

This short hand way of writing BPFs works, up to a point. Once we have to represent a value greater than 9, this binary shortcut breaks down.

In that case you need to write the BPF in hexadecimal, so lets rewrite our BPF in hex and get used to writing them that way.

In hex our value would be 0x02, so the BPF would be tcp[13] = 0x02. In hex, each digit represents a nibble, or 4 bits, so two digits in hexadecimal equal a byte.

So we see here none of the first four bits are set (0) and in the second nibble the SYN flag is set, which is 2 to the power of 1, or 2. What's with the 0x in front of our numbers? 

0x tells our computer this is a hexadecimal value. Octal numbers are prefaced by just a o, or more recently, 0o so 0o5 would be an octal 5 (octal is base 8 and we don't need to delve into that here).

Just as binary is base2, and decimal is base10, hexadecimal is base16. That means in hex we run out of numbers before we get to 15 and move to the next higher place. So How do we accomplish that?

Hexadecimal uses letters to represent the numbers 10 through 15. A=10, B=11, C=12, D=13, E=14 and F=15. So 0x1A is the hexadecimal number 26. 16 plus 10. 

Sunday, January 24, 2021

Pcaps and the Tools That Love Them Part 2

There's more to a primitive under the surface, and once we discover what it's actually doing, it opens up a whole new way for us to inspect and filter packets. 


Lets use the TCP primitive as an example. What is it actually doing? How does it show us only TCP packets? 


To see this we need to look at the IP header..not the TCP header. Here's a really simple version of a nicely color coded diagram.


Now we can see in the IP header we have a field called Protocol, or more accurately, Embedded Protocol. This signifies the next layer protocol embedded in the packet. 

If that field is 01, we have an ICMP packet. If it's 06, it's TCP. If it's 0x11 hex, or 17 in decimal, it's UDP.


So the tcp primitive is checking the Protocol field and seeing if that field contains 6, and if so it passes the packet on to be displayed or captured. 


Now, what field IS that. When counting header fields we start counting at zero. So we can count from the beginning of the packet and see that the protocol field is field 9.

Not clear from the diagram? You're right, it's not..too simple now..here's one showing the number of bits in each field.


Now we can see each line is 4 bytes, 23 bits. And starting from zero and counting the bytes we find Protocol in the ninth field.

The first two fields are divided into half bytes, call nibbles, 4 bits each. Just count them both as one byte. 

We'll cover what they do later and why the authors who wrote the protocol divided them up.

Most fields in the protocol header break on byte, or nibble (half byte) boundaries.

There are a few notable examples, which we'll cover as we look at bitmasking. Bitmasking can be simply defined as showing only the bits you need to see and masking out the others.


The same principles apply to any protocol. If there's a header, you can parse it. 

Getting yourself a good set of diagrams, in the format and layout YOU like is really going to help you. Unless you're in the rare position of doing nothing but analyzing packets all day, you're not going to memorize the protocol headers, probably. 

But from practice, you will remember the embedded protocol is in the ninth byte offset from zero in the IP header, or the flags bits are in the 13th byte in the TCP header, or the IP version is in the most significant 4 bits of byte 0 in the IP header. 

Without bunny trailing into big endian and little endian, for the purposes of packet inspection just remember that network byte order always starts from the left (you start counting at the leftmost bit and move right).


So to make this practical (and start at the beginning), the first byte of the IP header (byte zero) is split in half. The first four bits are the IP 

The second 4 bits, or nibble, is the header length. This is a value multiplied by 4. A normal IP header, with no options, is 20 bytes, so this should normally be 5.


Now that's your first visual clue when looking at a packet capture in hex. If the capture included the Ethernet header and you're looking for the start of the IP header, it SHOULD, but isn't always, be 45.






So if you see a packet capture and don't know what it is, a quick way to start orienting yourself is to look for a 45 byte.





Saturday, January 16, 2021

Pcaps and the Tools That Love Them Part 1

There are many pcap tools available and which ones you use really depends on what you're using them for. Some are very good at just giving you the raw data, others parse the data and show you certain types of packets..

But maybe we should back up one step and define what we're taking about. What is a pcap? Simply put, a pcap is a binary file that contains packets captured off of a network interface.

How much data, and which fields depends on the manner that you capture the packets. We'll look at some of those options as look at tcpdump. I won't spend a lot of time on that tool because many people are familiar with it, at least the basics. It's actually a powerful tool when combined with BPFs, but we'll cover that as well later.

BPFs is short for Berkeley Packet Filters and they allow pcap tools to get granular down to the bit, the BIT, level in specifying what header fields you want to see. For example, the TCP flags are each one bit in size. With BPFs you can specify to your tool to only show you packets that the SYN flag is set. Or SYN and any other combination of flags

The simplest BPFs are built in to tcpdump. As Brandon pointed out "tcp" and "port" are primitives. Others include udp, src dst, icmp, host and ether and net.

Other tools built on the libpcap library can use them as well, tools like ngrep and  tshark.

An example would be tcpdump -nn -i eth0 'tcp and port 23' (edited) 

This would tell tcpdump to listen on the eth0 interface, don't resolve hostnames, don't do port resolution, and only show packets that are the TCP protocol and either the source or destination port is 23.

If we only wanted to see traffic going to port 23, we could add the primitive dst in front of port.

tcpdump -nn -i eth0 'tcp and dst port 23'

Get into the habit of putting your BPF's into single quotes.

It will make no difference using simple BPFs like "port 80 or port 443", but when you get into complex BPFs using bitmasking, it will keep you from getting syntax errors.

So why use the -nn options, that disable name and port resolution? There are several reasons. One reason is speed and efficiency. 

If your sniffing a fast, busy segment and have to do a DNS lookup on every address, it will slow tcpdump down to the point of starting to drop packets. 

Another reason is if you're monitoring malicious traffic and the attacker controls his/her nameserver, they will see the DNS lookup and know they're being monitored by you. 

Port resolution is done using nmaps own services file, nmap-services instead of the default one in /etc/. This is a mapping of ports to services, so when tcpdump sees port 80 it substitutes http for 80. 

But can other services be bound to port 80? If you're root you can bind any service you like to any port you want. That port 80 traffic could be any protocol. So we'll bypass the commonly used ports and see what the traffic is ourselves.


Thursday, December 10, 2020

Being a Defender

 1. Be a student of (information security, network security, cyber security). Always strive to know what the latest tactics, trends, and tools are and implement that knowledge into Operations.

2. Never allow a vendor to define what your greatest risk is. It will undoubtably be something their  product detects well but be a low risk to your environment.

3. Be passionate about what you do. If you're looking for a 8 to 5 job you can forget about when you go home, information security may not be for you, to paraphrase Lesley Carhart. 

4. Be a an advocate for what your company really needs as far as tools. There is a marked over-reliance on tools in the industry and not nearly enough emphasis on training and development, but you know from experience what tools you truly need. 

5. Build the case, make the pitch, show verifiable results if you can. If you lose the battle, find an open source tool that does the same functionality without all the fancy reporting. Those reports aren't for you anyways; they're for the C-suite. 

6. Cross train as often as you can. Learn as much as you can about penetration testing tools, because hackers and Red Teamers alike use some of the same tools. Using a tool will help you learn what to look for.

7. Always push for more logs, more packets, more flow data. Anywhere and everywhere you can. Your dataset is your bread and butter; the more complete it is, the better chance you'll have in detecting or even preventing an attack.

8. Don't dwell on defeats. Learn from it and move on. You'll see plenty of them, both from attackers and internally fighting for what you really need.

9. Ask to be present at every meeting, call, or demo with a vendor. Management can't always distinguish what is practical from the vendor hype and BS. Be the one to challenge their over-realistic claims and make them back them up with something more than carefully crafted demo data, tuned for maximum detection by their product.

10, Don't stay up nights worrying about nation states/intelligence agencies or highly funded, highly skilled APT entities. If they want in, they are going to get in. Your job is to make sure your company isn't the low hanging fruit. 

11. To quote Mike Poor, prevention is optimal but detection is essential. Looking beyond the initial compromise and seeing what happened next is critical. Piecing together what the attacker did from disparate, seemingly unrelated pieces of information is something humans do better than machines, at least for now.



Sunday, November 29, 2020

SANS Virtual Summits 2021

 SANS has announced ALL of their Virtual Summits in 2021 will be free. See the link below for details..

Way to go SANS! That's giving back to the community..


https://www.sans.org/blog/sans-virtual-summits-free-2021/


Saturday, November 28, 2020

Intrusion Analysis 101

 If you're new to NetSec, you'll quickly find out network security is one of many silos in information security, and network security itself has many different roles.  One of these roles is the intrusion analyst.

What exactly is an intrusion analyst? Duties can differ according to the size of the team you join, what type of platforms and tools are employed, but at the lowest common denominator, an intrusion analyst monitors security systems and investigates the alerts they produce.

This may encompass a SIEM, IPS, EDR, firewall logs and others.

SIEM: Security Information and  Event Management

https://www.varonis.com/blog/what-is-siem/

IPS: Intrusion Prevention System

https://www.forcepoint.com/cyber-edu/intrusion-prevention-system-ips

EDR: Endpoint Detection and Response


Once an alert is received, triage begins. Many alerts can quickly be identified as false positives, generated from known benign processes. These are candidates for the continual process of tuning the SIEM and/or IPS. Without this process, the sheer number of FPs can begin to overwhelm  the analyst. Automation has come a long way in doing triage for the analyst, and machine learning is helpful, but no system can replace the need for human inspection of many of the alerts. 

Experience, tribal knowledge, awareness of changes in the network, applications used, integrations with vendors and business partners and again, experience, are skills ML or AI is not yet able to duplicate, if ever.

Is the intrusion analyst an incident responder? This again depends on the size of the team. Optimally, the intrusion analyst, after triaging an alert, would hand it off to an incident responder if action were necessary. This could anything from removing malware or re-imaging a machine to blocking IPs or applying isolation, either from the EDR solution or by network port shunning.

The reality is at most small and mid sized companies, the intrusion analyst will double as the/a incident responder, which is unfortunate. Not only does this require twice the amount of training and continual education, but it also means while the intrusion analyst is responding to an incident, he/she is not triaging alerts. 



Tuesday, October 27, 2020

Sooty - A SOC Analysts Tool - Part I

 Sooty is a SOC analysts tool that would also work well for an individual intrusion analyst. It's available at https://github.com/TheresAFewConors/Sooty. I've installed it on a Fedora test box at my day job; I'm going to install it on one of my laptops at home and go through the steps here as I had to track down a couple of dependencies to get it installed correctly on Fedora 32.

GitHubGitHub
The SOC Analysts all-in-one CLI tool to automate and speed up workflow. - TheresAFewConors/Sooty

The first step is to become root and change to where you want to install it. I use the /opt directory for stand alone tools. 


Now use git to pull down the Sooty. You can use subversion as well if you like.
Change to the Sooty directory


To install the prereqs, run pip install -r requirements.txt
On Fedora, I don't get a clean install becuase I'm missing libffi 

Install libffi



I'm still missing a prereq, Python.h

Install the devel package...


And run pip one last time...

And now we have satisfied all the requirements and gotten Sooty where it will run.

Are we done? Depends..

f you have API keys for Virustotal, URLScan.io, AbuseIPDB, HaveIBeenPwned or PhishTank, you need to make a copy of example_config.yaml, put your API keys on the appropriate lines and save it as config.yaml.

Otherwise, you can run the program, just not with the added functionality you would have if you have API keys.




That's the install, at least for Fedora. Other distros may require other prereqs, or may not need any fiddling at all. In the second part, we'll plug an API key in and start playing with the different options



Tuesday, September 22, 2020

Quick Tip #6

Sorting a list of IPs the proper way requires sorting on all four fields (octets). Hal Pomeranz presented this in the Linux DoJo 2 webinar on Black Hills Security webcast. 


Thursday, August 20, 2020

Quick Tip #5

 Find the interfaces in Linux that have IPs assigned (and what those IPs are):


ifconfig | grep -B1 -P -e "\d*\d\.\d*\d\.\d*\d\.\d*\d"


[root@rtrispa02 user1]# ifconfig | grep -B1 -P -e "\d*\d\.\d*\d\.\d*\d\.\d*\d"

enp1s0f0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet 10.82.250.27  netmask 255.255.255.255  broadcast 10.82.250.27

--

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536

        inet 127.0.0.1  netmask 255.0.0.0

Friday, May 15, 2020

Quick Tip #4 - Dshell

Dshell is a network forensics tool that extracts data from network traffic, either from a pcap or live from a network interface.

You can us Git or Subversion to install the tool.

[root@legolas opt]# git clone https://github.com/USArmyResearchLab/Dshell.git
Cloning into 'Dshell'...
remote: Enumerating objects: 29, done.
remote: Counting objects: 100% (29/29), done.
remote: Compressing objects: 100% (22/22), done.
remote: Total 653 (delta 9), reused 17 (delta 7), pack-reused 624
Receiving objects: 100% (653/653), 924.42 KiB | 4.26 MiB/s, done.
Resolving deltas: 100% (292/292), done.
[root@legolas opt]# ls
Dshell  google
[root@legolas opt]#

Next is installing the dependencies.

There's no Fedora package for pypcap, so here I had to use pip for that one package...
[jeff@legolas opt]$ sudo pip install pypcap
[sudo] password for jeff:
DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7.
WARNING: Running pip install with root privileges is generally not a good idea. Try pip install --user instead.
Collecting pypcap
  Using cached https://files.pythonhosted.org/packages/12/71/a689ca8c6ef4570e105efdc6b46d4ac16cdef7af36a8fbfaff0f6fa2b754/pypcap-1.2.3.tar.gz
Installing collected packages: pypcap
  Running setup.py install for pypcap ... done
Successfully installed pypcap-1.2.3
And install the rest of the prereqs...
[root@legolas opt]# dnf install geoip python2-dpkt  python2-IPy pycrypto
[root@legolas opt]# dnf install geoip python2-dpkt  python2-IPy pycrypto
Last metadata expiration check: 0:08:56 ago on Mon 23 Mar 2020 07:18:53 PM EDT.
Package GeoIP-1.6.12-5.fc30.x86_64 is already installed.
Package python2-crypto-2.6.1-25.fc30.x86_64 is already installed.
Dependencies resolved.
============================================================================================================================================================================
 Package                                     Architecture                          Version                                      Repository                             Size
============================================================================================================================================================================
Installing:
 python2-IPy                                 noarch                                0.81-24.fc30                                 fedora                                 37 k
 python2-dpkt                                noarch                                1.9.1-7.fc30                                 fedora                                261 k
Transaction Summary
============================================================================================================================================================================
Install  2 Packages
Total download size: 298 k
Installed size: 1.4 M
Is this ok [y/N]: y
Downloading Packages:
(1/2): python2-IPy-0.81-24.fc30.noarch.rpm                                                                                                   86 kB/s |  37 kB     00:00
(2/2): python2-dpkt-1.9.1-7.fc30.noarch.rpm

Once the prereqs are satisfied, run make from the Dshell directory.
Once it successfully completes. run ./dshell. If you see a dshell command prompt, you're good to go..
[root@legolas Dshell]# ./dshell
root@legolas.net.att:/opt/Dshell Dshell>
Now run decode -l to get a list of available decoders..

root@legolas.net.att:/opt/Dshell Dshell> decode -l
  module                                   name                           author            desc
  ---------------------------------------- ------------------------------ ---------- --- -  --------------------------------------------------
  decoders.dhcp.dhcp                       dhcp                           dek        UDP    Extract client information from DHCP messages
  decoders.dns.dns                         dns                            bg/twp     TCP    extract and summarize DNS queries/responses (defaults: A,AAAA,CNAME,PTR records)
  decoders.dns.dns-asn                     dns-asn                        bg         TCP    identify AS of DNS A/AAAA record responses
  decoders.dns.dns-cc                      dns-cc                         bg         TCP    identify country code of DNS A/AAAA record responses
  decoders.dns.innuendo-dns                innuendo-dns                   primalsec  TCP    proof-of-concept detector for INNUENDO DNS channel
  decoders.dns.reservedips                 reservedips                    bg         TCP    identify DNS resolutions that fall into reserved ip space
  decoders.filter.asn-filter               asn-filter                     twp/nl     TCP +  filter connections on autonomous system number (ASN)
  decoders.filter.country                  country                        twp        TCP +  filter connections on geolocation (country code)
  decoders.filter.snort                    snort                          twp        RAW +  filter packets by snort rule
  decoders.filter.track                    track                          twp        TCP +  tracked activity recorder
  decoders.flows.large-flows               large-flows                    bg         TCP    display netflows that have at least 1MB transferred
  decoders.flows.long-flows                long-flows                     bg         TCP    display netflows that have a duration of at least 5mins
  decoders.flows.netflow                   netflow                        bg         TCP    generate netflow information from pcap
  decoders.flows.reverse-flow              reverse-flow                   me         TCP    Generate an alert if the client transmits more data than the server
  decoders.ftp.ftp                         ftp                            amm        TCP    ftp
  decoders.http.flash-detect               flash-detect                   ekilmer    TCP +  Detects successful Flash file download.
  decoders.http.httpdump                   httpdump                       amm        TCP    Dump useful information about HTTP sessions
  decoders.http.joomla-cve-2015-8562       joomla-cve-2015-8562           bg         TCP    detect and dissect malformed HTTP headers targeting Joomla
  decoders.http.ms15-034                   ms15-034                       bg         TCP    detect attempts to enumerate MS15-034 vulnerable IIS servers
  decoders.http.peht                       peht                           mm         TCP    Penetration/Exploit/Hijacking Tool detector
  decoders.http.rip-http                   rip-http                       bg/twp     TCP    rip files from HTTP traffic
  decoders.http.web                        web                            bg,twp     TCP    Improved version of web that tracks server response
  decoders.malware.emdivi.emdivi_c2        emdivi_c2                      bg         TCP    deobfuscate Emdivi http c2
  decoders.misc.followstream               followstream                   amm        TCP    Generates color-coded Screen/HTML output similar to Wireshark Follow Stream
  decoders.misc.grep                       grep                           amm        TCP +  Search for patterns in streams.
  decoders.misc.merge                      merge                          bg/twp     RAW +  dump all packets to single file
  decoders.misc.synrst                     synrst                         bg         RAW    detect failed attempts to connect (SYN followed by a RST/ACK)
  decoders.misc.writer                     writer                         twp        RAW    pcap/session writer
  decoders.misc.xor                        xor                            twp        TCP +  XOR an entire stream with a given single byte key
  decoders.nbns.nbns                       nbns                           dek        UDP    Extract client information from NBNS traffic
  decoders.protocol.bitcoin                bitcoin                        dek        TCP    Extract Bitcoin traffic, including Stratum mining protocol (pooled) traffic
  decoders.protocol.ether                  ether                          twp        RAW    raw ethernet capture decoder
  decoders.protocol.ip                     ip                             twp        RAW    IPv4/IPv6 decoder
  decoders.protocol.protocol               protocol                       bg         RAW    Identifies non-standard protocols (not tcp, udp or icmp)
  decoders.smb.psexec                      psexec                         amm        TCP    Extract command/response information from psexec over smb
  decoders.smb.rip-smb-uploads             rip-smb-uploads                bg         TCP    Extract files uploaded via SMB
  decoders.smb.smbfiles                    smbfiles                       amm        TCP    List files accessed via smb
  decoders.templates.PacketDecoder         unnamed                        xx         RAW
  decoders.templates.SessionDecoder        unnamed                        xx         TCP
  decoders.tftp.tftp                       tftp                           dev195     RAW    Find TFTP streams and, optionally, extract the files
  decoders.voip.rtp                        rtp                            mm         UDP    Real-time transport protocol (RTP) capture decoder
  decoders.voip.sip                        sip                            mm         UDP    Session Initiation Protocol (SIP) capture decoder
  root@legolas.net.att:/opt/Dshell Dshell>

Once in the Dshell prompt, use decode to start analysis, whether from a network interface or a pcap.
the syntax is decode -d <decoder> <source>
So to run the DNS extraction decoder from a network interface, the syntax would be decode -d dns -i <interface>
If you use tcpdump, ngrep or other libpcap tools, -i is easy to remember...

root@legolas.net.att:/opt/Dshell Dshell> decode -d dns -i eno1
dns 2020-03-24 15:57:02      192.168.1.1:53    --      192.168.1.4:44085 ** 34186 A? i.scdn.co / CNAME: scdnco.spotify.map.fastly.net, A: 151.101.46.248 (ttl 6s) **
dns 2020-03-24 15:57:02      192.168.1.1:53    --      192.168.1.4:44085 ** 38801 AAAA? i.scdn.co / CNAME: scdnco.spotify.map.fastly.net, AAAA: 2a04:4e42:b::760 (ttl 6s) **
dns 2020-03-24 15:57:10      192.168.1.1:53    --      192.168.1.4:36947 ** 9265 A? www.gstatic.com / A: 172.217.8.163 (ttl 156s) **
dns 2020-03-24 15:57:10      192.168.1.1:53    --      192.168.1.4:36947 ** 1339 AAAA? www.gstatic.com / AAAA: 2607:f8b0:4009:810::2003 (ttl 168s) **
dns 2020-03-24 15:57:10      192.168.1.1:53    --      192.168.1.4:43795 ** 3600 A? clientservices.googleapis.com / A: 172.217.6.3 (ttl 172s) **
dns 2020-03-24 15:57:10      192.168.1.1:53    --      192.168.1.4:58426 ** 18791 AAAA? www.googleapis.com / AAAA: 2607:f8b0:4009:816::200a (ttl 9s) **
dns 2020-03-24 15:57:10      192.168.1.1:53    --      192.168.1.4:43795 ** 33050 AAAA? clientservices.googleapis.com / AAAA: 2607:f8b0:4009:816::2003 (ttl 21s) **
dns 2020-03-24 15:57:10      192.168.1.1:53    --      192.168.1.4:58426 ** 9310 A? www.googleapis.com / A: 172.217.4.74 (ttl 156s) **
dns 2020-03-24 15:57:10      192.168.1.1:53    --      192.168.1.4:42267 ** 29350 A? accounts.google.com / A: 172.217.5.13 (ttl 109s) **
dns 2020-03-24 15:57:10      192.168.1.1:53    --      192.168.1.4:42267 ** 11695 AAAA? accounts.google.com / AAAA: 2607:f8b0:4009:806::200d (ttl 180s) **
dns 2020-03-24 15:57:11      192.168.1.1:53    --      192.168.1.4:41977 ** 37896 A? www.google.com / A: 172.217.5.4 (ttl 24s) **
dns 2020-03-24 15:57:11      192.168.1.1:53    --      192.168.1.4:41977 ** 1809 AAAA? www.google.com / AAAA: 2607:f8b0:4009:816::2004 (ttl 115s) **
dns 2020-03-24 15:57:11      192.168.1.1:53    --      192.168.1.4:38453 ** 2485 AAAA? mirror.toolbar.netcraft.com / CNAME: d2nwnd7jypv9mn.cloudfront.net **
dns 2020-03-24 15:57:11      192.168.1.1:53    --      192.168.1.4:38453 ** 22186 A? mirror.toolbar.netcraft.com / CNAME: d2nwnd7jypv9mn.cloudfront.net, A: 54.192.30.37 (ttl 60s), A: 54.192.30.3 (ttl 60s), A: 54.192.30.121 (ttl 60s), A: 54.192.30.32 (ttl 60s) **
dns 2020-03-24 15:57:11      192.168.1.1:53    --      192.168.1.4:54375 ** 40826 AAAA? oauthaccountmanager.googleapis.com / AAAA: 2607:f8b0:4009:80e::200a (ttl 67s) **
dns 2020-03-24 15:57:11      192.168.1.1:53    --      192.168.1.4:54375 ** 18283 A? oauthaccountmanager.googleapis.com / A: 172.217.1.42 (ttl 239s) **
dns 2020-03-24 15:57:11      192.168.1.1:53    --      192.168.1.4:43085 ** 3682 A? www.gstatic.com / A: 172.217.8.163 (ttl 155s) **
dns 2020-03-24 15:57:11      192.168.1.1:53    --      192.168.1.4:43085 ** 47980 AAAA? www.gstatic.com / AAAA: 2607:f8b0:4009:810::2003 (ttl 167s) **
dns 2020-03-24 15:57:11      192.168.1.1:53    --      192.168.1.4:52599 ** 24895 A? fonts.gstatic.com / CNAME: gstaticadssl.l.google.com, A: 172.217.4.227 (ttl 151s) **
dns 2020-03-24 15:57:11      192.168.1.1:53    --      192.168.1.4:52599 ** 17736 AAAA? fonts.gstatic.com / CNAME: gstaticadssl.l.google.com, AAAA: 2607:f8b0:4009:813::2003 (ttl 184s) **
dns 2020-03-24 15:57:14      192.168.1.1:53    --      192.168.1.4:34639 ** 6929 A? clients2.google.com / CNAME: clients.l.google.com, A: 172.217.6.110 (ttl 200s) **
dns 2020-03-24 15:57:14      192.168.1.1:53    --      192.168.1.4:34639 ** 22810 AAAA? clients2.google.com / CNAME: clients.l.google.com, AAAA: 2607:f8b0:4009:80c::200e (ttl 80s) **
dns 2020-03-24 15:57:14      192.168.1.1:53    --      192.168.1.4:38872 ** 56630 A? mtalk.google.com / CNAME: mobile-gtalk.l.google.com, A: 74.125.201.188 (ttl 200s) **
dns 2020-03-24 15:57:14      192.168.1.1:53    --      192.168.1.4:54398 ** 38080 AAAA? clients4.google.com / CNAME: clients.l.google.com, AAAA: 2607:f8b0:4009:813::200e (ttl 65s) **
dns 2020-03-24 15:57:14      192.168.1.1:53    --      192.168.1.4:38872 ** 8511 AAAA? mtalk.google.com / CNAME: mobile-gtalk.l.google.com, AAAA: 2607:f8b0:4001:c14::bc (ttl 169s) **
dns 2020-03-24 15:57:14      192.168.1.1:53    --      192.168.1.4:54398 ** 16312 A? clients4.google.com / CNAME: clients.l.google.com, A: 172.217.8.174 (ttl 144s) **
dns 2020-03-24 15:57:14      192.168.1.1:53    --      192.168.1.4:48611 ** 36628 A? update.googleapis.com / A: 172.217.8.195 (ttl 169s) **
dns 2020-03-24 15:57:14      192.168.1.1:53    --      192.168.1.4:48611 ** 6685 AAAA? update.googleapis.com / AAAA: 2607:f8b0:4009:815::2003 (ttl 249s) **
dns 2020-03-24 15:57:15      192.168.1.1:53    --      192.168.1.4:51568 ** 18214 A? pbs.twimg.com / CNAME: cs196.wac.edgecastcdn.net, CNAME: cs2-wac.apr-8315.edgecastdns.net, CNAME: cs2-wac-us.8315.ecdns.net, CNAME: cs672.wac.edgecastcdn.net, A: 192.229.173.16 (ttl 1607s) **
dns 2020-03-24 15:57:15      192.168.1.1:53    --      192.168.1.4:51568 ** 30000 AAAA? pbs.twimg.com / CNAME: cs196.wac.edgecastcdn.net, CNAME: cs2-wac.apr-8315.edgecastdns.net, CNAME: cs2-wac-us.8315.ecdns.net, CNAME: cs672.wac.edgecastcdn.net, AAAA: 2606:2800:220:13d:2176:94a:948:148e (ttl 282s) **
dns 2020-03-24 15:57:15      192.168.1.1:53    --      192.168.1.4:45840 ** 10482 A? twitter.com / A: 104.244.42.65 (ttl 204s), A: 104.244.42.129 (ttl 204s) **
dns 2020-03-24 15:57:15      192.168.1.1:53    --      192.168.1.4:42808 ** 22387 A? ogs.google.com / CNAME: www3.l.google.com, A: 172.217.9.78 (ttl 79s) **
dns 2020-03-24 15:57:15      192.168.1.1:53    --      192.168.1.4:42808 ** 10107 AAAA? ogs.google.com / CNAME: www3.l.google.com, AAAA: 2607:f8b0:4009:813::200e (ttl 131s) **
dns 2020-03-24 15:57:15      192.168.1.1:53    --      192.168.1.4:53188 ** 47438 AAAA? ssl.gstatic.com / AAAA: 2607:f8b0:4009:803::2003 (ttl 51s) **
dns 2020-03-24 15:57:15      192.168.1.1:53    --      192.168.1.4:53188 ** 46402 A? ssl.gstatic.com / A: 172.217.1.35 (ttl 212s) **
8:58
This is just a simple example, of course. Dshell has some really powerful decoders.

Also realize when decoding from a network interface, your results will not be instantaneous. DShell is both sniffing, and processing the packets. It may take a few seconds before you see output to the screen..

Over time, we get a nice list of DHCP clients..

root@legolas.net.att:/opt/Dshell Dshell> decode -d dhcp -i wlp2s0
WARNING:dhcp:unpack requires a string argument of length 7
dhcp 2020-03-25 08:06:03         0.0.0.0:68   -- 255.255.255.255:67   ** Transaction ID: 0xcc7bea4a  Client Hostname: DESKTOP-G7F5AG0 Client MAC: 00:db:df:82:39:a8
**
dhcp 2020-03-25 11:45:32         0.0.0.0:68   -- 255.255.255.255:67   ** Transaction ID: 0x1fd67e34  Client Hostname: android-2dc255debbc724e1 Client MAC: e0:db:10:4f:
58:95   **
dhcp 2020-03-25 11:48:48         0.0.0.0:68   -- 255.255.255.255:67   ** Transaction ID: 0x3b0ac447  Client Hostname: android-2dc255debbc724e1 Client MAC: c4:1c:ff:a1:
11:62   **
dhcp 2020-03-25 11:48:49         0.0.0.0:68   -- 255.255.255.255:67   ** Transaction ID: 0x3b0ac447  Client Hostname: android-2dc255debbc724e1 Client MAC: c4:1c:ff:a1:
11:62   **
dhcp 2020-03-25 11:57:47         0.0.0.0:68   -- 255.255.255.255:67   ** Transaction ID: 0xeef4a9b   Client Hostname: DESKTOP-G7F5AG0 Client MAC: 00:db:df:82:39:a8
**
dhcp 2020-03-25 12:04:07         0.0.0.0:68   -- 255.255.255.255:67   ** Transaction ID: 0xb096d028  Client Hostname: DESKTOP-G7F5AG0 Client MAC: c4:1c:ff:a1:11:62
**
dhcp 2020-03-25 12:04:08         0.0.0.0:68   -- 255.255.255.255:67   ** Transaction ID: 0xb096d028  Client Hostname: DESKTOP-G7F5AG0 Client MAC: c4:1c:ff:a1:11:62
**
dhcp 2020-03-25 12:48:32         0.0.0.0:68   -- 255.255.255.255:67   ** Transaction ID: 0x9224c4a1  Client Hostname: WINDOWS-F8POIBL Client MAC: 00:db:df:f1:0a:1d
**
dhcp 2020-03-25 12:55:12         0.0.0.0:68   -- 255.255.255.255:67   ** Transaction ID: 0x1968796   Client Hostname: SAMSUNG-SM-G950U Client MAC: dc:ef:ca:ce:fb:eb
 **
dhcp 2020-03-25 14:00:37         0.0.0.0:68   -- 255.255.255.255:67   ** Transaction ID: 0xffcab1c1  Client Hostname: android-7eb55e3b2dff69c7 Client MAC: c8:a8:23:9a:
bd:36   **
dhcp 2020-03-25 14:23:47         0.0.0.0:68   -- 255.255.255.255:67   ** Transaction ID: 0xa460cc0f  Client Hostname: Living room    Client MAC: c8:a8:23:9a:bd:36

Running Dshell from a pcap

Running dshell against a pcap is as simple as specifying the decoder (-d) then the filename:

decode -d dns test01-200330-00152961.pcap
34.192.146.205 (ttl 43s), A: 3.210.88.27 (ttl 43s), A: 3.214.228.175 (ttl 43s), A: 3.225.196.127 (ttl 43s), A: 3.226.155.212 (ttl 43s), A: 3.230.54.175 (ttl 43s), A: 18.211.68.147 (ttl 43s), A: 18.233.141.189 (ttl 43s) **
dns 2020-03-30 16:15:37   208.67.222.222:53    --      12.68.84.27:48513 ** 43640 A? tps10251.doubleverify.com / CNAME: nycp-hlb.doubleverify.com, CNAME: nycp-hlb.dvgtm.akadns.net, A: 204.154.111.119 (ttl 57s) **
dns 2020-03-30 16:15:37      10.82.17.91:53    --     10.84.81.106:62178 ** 44144 A? sqm.microsoft.com / CNAME: sqmfe.glbdns2.microsoft.com **
dns 2020-03-30 16:15:37      10.82.17.91:53    --    10.84.195.218:52695 ** 40361 A? teams.microsoft.com / CNAME: teams.office.com, CNAME: teams-office-com.s-0005.s-msedge.net, CNAME: s-0005.s-msedge.net, A: 52.113.194.132 (ttl 74s) **
dns 2020-03-30 16:15:37      10.70.12.72:53    --     10.84.196.47:60102 ** 38924 A? eastus.notifications.teams.microsoft.com / CNAME: eastuscns.trafficmanager.net, CNAME: eastuscns-16.eastus.cloudapp.azure.com, A: 52.114.133.8 (ttl 10s) **
A: 67.226.212.59 (ttl 163s), A: 67.226.212.60 (ttl 163s), A: 67.226.212.55 (ttl 163s), A: 67.226.212.56 (ttl 163s) **
dns 2020-03-30 16:15:37      10.82.17.91:53    --    10.84.194.198:56018 ** 33928 A? southcentralus.notifications.teams.microsoft.com / CNAME: southcentraluscns.trafficmanager.net, CNAME: southcentraluscns-28.southcentralus.cloudapp.azure.com, A: 52.114.144.25 (ttl 10s) **
dns 2020-03-30 16:15:37      10.70.12.72:53    --    10.84.194.198:56018 ** 33928 A? southcentralus.notifications.teams.microsoft.com / CNAME: southcentraluscns.trafficmanager.net, CNAME: southcentraluscns-28.southcentralus.cloudapp.azure.com, A: 52.114.144.25 (ttl 4s) **
dns 2020-03-30 16:15:37      10.82.17.91:53    --     10.84.196.72:55455 ** 29864 A? cdn.syndication.twimg.com / CNAME: cs196.wac.edgecastcdn.net, CNAME: cs2-wac.apr-8315.edgecastdns.net, CNAME: cs2-wac-us.8315.ecdns.net, CNAME: cs45.wac.edgecastcdn.net, A: 72.21.91.70 (ttl 882s) **
dns 2020-03-30 16:15:37      10.82.17.91:53    --     10.84.81.106:51938 ** 44545 A? sqm.microsoft.com / CNAME: sqmfe.glbdns2.microsoft.com **
dns 2020-03-30 16:15:37   208.67.220.220:53    --      12.68.84.27:54400 ** 45921 A? acp-ss.adobe.io / A: 52.0.111.85 (ttl 60s), A: 52.0.166.103 (ttl 60s), A: 52.1.255.31 (ttl 60s), A: 52.20.40.93 (ttl 60s), A: 52.21.18.122 (ttl 60s), A: 52.22.128.58 (ttl 60s), A: 35.172.75.11 (ttl 60s), A: 52.0.102.100 (ttl 60s) **

Blog Archive