I like to travel, f*ck with technology, and partake in the occasional tropical drink.
I am also a co-host on The NBD Show podcast.
Follow Me


InfoCon.org is a noncommercial community-supported website that hosts the largest archive of past hacking-related convention material on the planet. It amazing how extensive their collection of video, audio, hacker documentaries, wordlists, rainbow tables, podcasts, the content goes on and on.
You have to check it out for yourself, you can get lost hours, days even weeks there is so much content.

Check them out and show them some love.



**Update June 5th, 2021** There have been some questions about Defcon in person attendance and masks, especially as Las Vegas will have officially reopened completely. Dark tangent made it clear in a post on the Defcon Forums, “If a law forces us to allow people to not wear masks we would cancel the event” , if you want to read the entire conversation check it out here. https://forum.defcon.org/node/237012/page2#post237285

Dark Tangent, the founder and organizer of Defcon, just posted in the Defcon forums that the conference going to go hybrid this year.  Here is a link to his post: https://forum.defcon.org/node/236655.  DT admittedly says things are still fluid but they wanted to put out the information to help people make the decision if they are going to go virtually or in person. Now that the Goons are going to be yelling "space it out" instead of  "squeeze it in" It's going to feel like Defcon in a parallel universe.


There will also be some unprecedented changes this year that I wanted to outline below. Again things might change but these where the highlights from DT's post. I will add the preregistration link on this post when they release it later this month.

  • Defcon will be held both online and in person.

  • To attend in person you are required to wear a mask and be vaccinated.

  • Defcon will have socially distance seating and tables, and the convention properties will have increased air circulation and filtering.

  • For the first time Defcon will have online pre-registration for the in-person conference. The registration platform has not been selected, but they are encouraging in person attendees to preregister by insuring they will get a physical conference badge.  DT mentions that they need hard numbers of attendees to help them with planning the event.

  • They are going to order extra badges for those who show up with cash on-site, but if they guess wrong on quantity you may getting a paper badge, and if they are at capacity you could be turned away. 

  • Defcon will be throwing only the Black and White ball, entertainment. and pool parties this year. They will not be planning or organizing smaller parties.

  • Defcon has asked everyone, villages included, to pre-record all talks. Should they have to go full virtual, they won’t have a last-minute disaster of trying to capture the talks. This way DEF CON can release talks on Twitch like last year.

  • Should you be in-person and want to give your talk live they can do that, or do Q&A, or remote Q&A. Pre-recording gives Defcon options and allows everyone to see the talks. Yes, DCTV will be happening so you can also watch in your hotel room.


DT also listed some of the assumptions they have been working with while trying to organize Defcon this year. 

  • Almost no international attendees will attend in-person. The quarantine times and lower vaccination rates mean it is not very realistic, so we hope they will join us on-line instead.

  • That everyone in our demographic who is capable and wants a vaccination will have gotten one by the end of June.

  • Our in-person attendance will be ¼ to ½ normal, and people will be changing their minds on whether or not to attend right up to the last minute – and that includes people organizing contests, events, and villages.

  • Not all Goons will be there in-person, and many will help out by Gooning virtually.

  • While there will be fewer attendees there will also be fewer villages, contests, and events. It should all balance out so attendees don’t fee like there are a million things to do but not enough people to do them with.

  • There will be hybrid events, where you can participate in-person as well as virtually, but doing this for every event is unfortunately too demanding for many contest and village organizers.


I am pretty excited that Defcon will have hybrid model this year. Defcon for me over the last almost 20 years of attendance is something I look forward to every year. Like most people your last day after the con - when your hung over, hot, and reek of cigarette smoke - you have those brief thoughts that “maybe I’ll take next year off”.  That only lasts a short time before your booking your hotel for next year. 


Welcome back Defcon!


Use Cases:

Since the COVID-19 pandemic, many companies have leveraged VDI Horizon infrastructure to accommodate their remote workers. Today remote users connect to VDI Horizon infrastructure over many different means home ISP connections, company-issued cellular devices/hotspots on multiple carriers, as well as personal devices. We have identified an issue with cellular devices traversing the ATT Wireless network connecting to VDI Horizon infrastructure.


The Architecture:

I wanted to simplify the VDI Horizons infrastructure discussion to just the pieces that are crucial to the issue. The relevant parts that come into play for user access to the Horizons environment is the VMWare Horizon client, hardware load balancers, and the UAG or User Access Gateway servers. 


The Protocols:

VDI Horizons traffic is split between primary and secondary protocols. The primary protocol used for authentication is over HTTPS or port 443. Within the ATT wireless network, this traffic is sourced from the primary enterprise PAT address. After the VMware Horizon client has authenticated and established secure communication to one of the UAG appliances, one or more secondary connections are made from the Horizon client. These secondary connections can include:

Blast Extreme display protocol (TCP 443 and UDP 8443). Note that UDP is optional with Blast.

PCoIP display protocol (TCP 4172 and UDP 4172).

The secondary Horizon protocols must be routed to the same UAG appliance and from the same client IP address that the primary Horizon protocol was authenticated from. The UAG authorizes the secondary protocols based on the authenticated user session. The UAG will only forward traffic into the corporate data center on behalf of an authenticated user.

The Symptoms:

On the ATT Wireless network when a user's Horizon client connects to a virtual IP address it is load balanced to a UAG server and the session is authenticated. The IP address of the traffic is sourced and authenticated using the device’s IP address, this is true for all networks. When the Horizon client attempts to connect to the secondary protocol the traffic destined to the secondary protocol port, UDP 8443, or TCP or UDP 4172, is routed through a proxy within the ATT network. When the traffic is routed through the ATT proxy the source IP address of that traffic is different than the original device IP that was used to authenticate the user session and the VMware UAG server rejects the traffic. In some situations, the load-balanced traffic may even be sent to a different UAG server. This seems to be true for all users on the ATT Wireless network.


Moving toward a solution:

The first part of solving the problem is identifying the cause, and we believe that is done. Since the IP address of the primary and secondary protocols are different, the Horizons server rejects the traffic or perhaps never sees the traffic based on load balancing and persistence settings of the load balancer. ATT network engineers have been very helpful with troubleshooting and validating that our assumptions are accurate and are currently looking at solutions to solve the issue. 

**Update** the ATT sales people that where interfacing with the ATT technical staff have informed us it is not possible to fix the issue.  They are trying to sell us a cellular router that they say can be routed over an APN to solve the issue, instead of letting the technical folks fix the issue for us and potentially everyone else on the ATT wireless network.

What would we like to see:

We would like to see the secondary protocols included in the enterprise PAT and not routed through the proxy. If this was implemented, it could fix VDI Horizons across the entire ATT Wireless environment for everyone.

So SolarStorm the SolarWinds supply chain hack... Yeah.... You might have heard about it? 


SolarWinds supply chain was compromised. What that means is a trojanized version of a SolarWinds  package was uploaded and distributed to their clients .  The infected package contained malware named SUNBURST, and when clients installed the infected package it also installed the malware.  The malware creates a backdoor to allow the bad actors to control the server, move laterally, and exfiltrate data. Basically what ever they want....



 Updated Solarwinds Attack Lifecycle:

What should you do now:


As information starts to come out and the initial freak out calms down we are learning more about the impact of these exploits, and they are pretty huge. I wanted to gather a collection of information and vendor responses in one place to try to help fellow nerds have a resource of reliable information. 



Fireeye Links

US Cybersecurity and Infrastructure Security Agency (CISA) 

Palo Alto Networks Unit 42

Check Point





 Elasticsearch (Elastic Security)
Link to Blog post about Reverse Engineering the encoded  DGAs:
** is a link that has been added. I will also highlight them in Bold font.


During the pandemic, I have been binging more and more Star Wars shows on Disney+. While I have been taking in all that Star Wars it hit me I wasn't sure when these individual shows or movies took place in the canon timeline. Shows like the Mandalorian throw in some deep-cut references that I didn't get until I understood when it took place.

So I wanted to put up a list in chronological order to help myself and hopefully, everyone else enjoy Star Wars a little bit more.


  • Episode I Phantom Menace
  • Episode II Attack of the Clones
  • Clone Wars (movie)
  • Clone Wars (tv show S1-7)
  • Episode III Revenge of the Sith
  • Solo: A Star Wars Story
  • Star Wars: Rebels (S1-4)
  • Rouge One: A Star Wars Story
  • Star Wars: A New Hope
  • Battlefront (video game)
  • The Empire Strikes Back
  • Return of the Jedi
  • Battlefront II (video game)
  • The Mandalorian
  • Star Wars: Resistance S1 (tv show)
  • The Force Awakens
  • Star Wars: Resistance S2 (tv show)
  • The Last Jedi
  • Rise of Skywalker

Also if you want more in depth info I found this interactive site that lists alot more then just TV and movies. https://starwarscanontimeline.com/




Dig (Domain Information Groper) is a powerful command-line tool for querying DNS name servers.

The dig command, like nslookup, allows you to query information about various DNS records, including host addresses, mail exchanges, and name servers. It is the most commonly used tool among system administrators for troubleshooting DNS problems because of its flexibility and ease of use.

This tutorial explains how to use the dig utility through practical examples and detailed explanations of the most common dig options.

To check if the dig command is available on your system type:

dig -v

The output should look something like this:

DiG 9.10.6

If dig is not present on your system, the command above will print “dig: command not found”. The dig tool can be installed using the distro’s package manager.

Quick command Cheat Sheet:


More in depth, understanding the dig Output:
In its simplest form, when used to query a single host (domain) without any additional options, the dig command is pretty verbose.

In the following example, we’re performing on the wirelessphreak.com domain:

dig wirelessphreak.com

The output should look something like this:

    ; <<>> DiG 9.10.6 <<>> wirelessphreak.com
     ;; global options: +cmd
     ;; Got answer:
     ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19643
     ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

    ; EDNS: version: 0, flags:; udp: 4096
     ;wirelessphreak.com.        IN    A

     wirelessphreak.com.    300    IN    A
     wirelessphreak.com.    300    IN    A
     wirelessphreak.com.    300    IN    A

    ;; Query time: 37 msec
    ;; SERVER:
    ;; WHEN: Mon Nov 16 12:16:45 PST 2020
    ;; MSG SIZE  rcvd: 95

Let’s go section by section and explain the output of the dig command: 

The first line of the output prints the installed dig version, and the queried domain name. The second line shows the global options (by default, only cmd).

    ; <<>>DiG 9.10.6 <<>> wirelessphreak.com
    ;; global options: +cmd

 If you don’t want those lines to be included in the output, use the +nocmd option. This option must be the very first one after the dig command.

 The next section includes technical details about the answer received from the requested authority (DNS server). The header shows the opcode (the action performed by dig) and the status of the action. In this example, the status is NOERROR, which means that the requested authority served the query without any issue.

    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19643
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1


This section can be removed using the +nocomments option, which also disables some other section’s headers.

The “OPT” pseudo section is shown only in the newer versions of the dig utility. You can read more about the Extension mechanisms for DNS (EDNS) here .

    ; EDNS: version: 0, flags:; udp: 4096

To exclude this section from the output, use the +noedns option.

In the “QUESTION” section dig shows the query (question). By default, dig requests the A record.

    ;wirelessphreak.com.            IN    A

You can disable this section using the +noquestion option.

The “ANSWER” section provides us with an answer to our question. As we already mentioned, by default dig will request the A record. Here, we can see that the domain wirelessphreak.com points to the three IP address.

    wirelessphreak.com.    300    IN    A
    wirelessphreak.com.    300    IN    A
    wirelessphreak.com.    300    IN    A


Usually, you do not want to turn off the answer, but you can remove this section from the output using the +noanswer option.

The “AUTHORITY” section tells us what server(s) are the authority for answering DNS queries about the queried domain. In this example it did not provide and authoritative server answer.


You can disable this section of the output using the +noauthority option.

The “ADDITIONAL” section gives us information about the IP addresses of the authoritative DNS servers shown in the authority section.


The +noadditional option disables the additional section of a reply.

The last section of the dig output includes statistics about the query.

    ;; Query time: 37 msec
    ;; SERVER:
    ;; WHEN: Mon Nov 16 12:16:45 PST 2020
    ;; MSG SIZE  rcvd: 95

You can disable this part with the +nostats option.

Printing Only the Answer
Generally, you would want to get only a short answer to your dig query.
1. Get a Short Answer

To get a short answer to your query, use the +short option:

dig wirelessphreak.com +short

The output will include only the IP addresses of the A record.
2. Get a Detailed Answer

For more a detailed answer, turn off all the results using the +noall options and then turn on only the answer section with the +answer option.

dig wirelessphreak.com +noall +answer

     ; <<>> DiG 9.10.6 <<>> wirelessphreak.com +noall +answer
     ;; global options: +cmd
     wirelessphreak.com.    300    IN    A
     wirelessphreak.com.    300    IN    A
     wirelessphreak.com.    300    IN    A

Query Specific Name Server
By default, if no name server is specified, dig uses the servers listed in /etc/resolv.conf file.

To specify a name server against which the query will be executed, use the @ (at) symbol followed by the name server IP address or hostname.

For example, to query the Google name server ( for information about the wirelessphreak.com domain you would use:

dig wirelessphreak.com @

     ; <<>> DiG 9.10.6 <<>> wirelessphreak.com @
     ;; global options: +cmd
     ;; Got answer:
     ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23065
     ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

     ; EDNS: version: 0, flags:; udp: 512
    ;wirelessphreak.com.        IN    A

    wirelessphreak.com.    299    IN    A
    wirelessphreak.com.    299    IN    A
    wirelessphreak.com.    299    IN    A

    ;; Query time: 31 msec
    ;; SERVER:
    ;; WHEN: Mon Nov 16 12:27:32 PST 2020
    ;; MSG SIZE  rcvd: 95

Query a Record Type
Dig allows you to perform any valid DNS query by appending the record type to the end of the query. In the following section, we will show you examples of how to search for the most common records, such as A (the IP address), CNAME (canonical name), TXT (text record), MX (mail exchanger), and NS (name servers).
1. Querying A records

To get a list of all the address(es) for a domain name, use the a option:

dig +nocmd google.com a +noall +answer

    google.com.        128    IN    A

As you already know, if no DNS record type is specified, dig will request the A record. You can also query the A record without specifying the a option.
2. Querying CNAME records

To find the alias domain name use the cname option:

dig +nocmd mail.google.com cname +noall +answer

    mail.google.com.    553482    IN    CNAME    googlemail.l.google.com.

3. Querying TXT records

Use the txt option to retrieve all the TXT records for a specific domain:

dig +nocmd google.com txt +noall +answer

    google.com.        300    IN    TXT    "facebook-domain-       verification=22rm551cu4k0ab0bxsw536tlds4h95"
    google.com.        300    IN    TXT    "v=spf1 include:_spf.google.com ~all"
    google.com.        300    IN    TXT    "docusign=05958488-4752-4ef2-95eb-aa7ba8a3bd0e"

4. Querying MX records

To get a list of all the mail servers for a specific domain use the mx option:

dig +nocmd google.com mx +noall +answer

    google.com.        494    IN    MX    30 alt2.aspmx.l.google.com.
    google.com.        494    IN    MX    10 aspmx.l.google.com.
    google.com.        494    IN    MX    40 alt3.aspmx.l.google.com.
    google.com.        494    IN    MX    50 alt4.aspmx.l.google.com.
    google.com.        494    IN    MX    20 alt1.aspmx.l.google.com.

5. Querying NS records

To find the authoritative name servers for our specific domain use the ns option:

dig +nocmd google.com ns +noall +answer

    google.com.        84527    IN    NS    ns1.google.com.
    google.com.        84527    IN    NS    ns2.google.com.
    google.com.        84527    IN    NS    ns4.google.com.
    google.com.        84527    IN    NS    ns3.google.com.

6. Querying All Records

Use the any option to get a list of all DNS records for a specific domain:

dig +nocmd google.com any +noall +answer

    google.com.        299    IN    A
    google.com.        299    IN    AAAA    2a00:1450:4017:804::200e
    google.com.        21599    IN    NS    ns2.google.com.
    google.com.        21599    IN    NS    ns1.google.com.
    google.com.        599    IN    MX    30 alt2.aspmx.l.google.com.
    google.com.        21599    IN    NS    ns4.google.com.
    google.com.        599    IN    MX    50 alt4.aspmx.l.google.com.
    google.com.        599    IN    MX    20 alt1.aspmx.l.google.com.
    google.com.        299    IN    TXT    "docusign=05958488-4752-4ef2-95eb-aa7ba8a3bd0e"
    google.com.        21599    IN    CAA    0 issue "pki.goog"
   google.com.        599    IN    MX    40 alt3.aspmx.l.google.com.
   google.com.        3599    IN    TXT    "facebook-domain-    verification=22rm551cu4k0ab0bxsw536tlds4h95"
    google.com.        21599    IN    NS    ns3.google.com.
    google.com.        599    IN    MX    10 aspmx.l.google.com.
    google.com.        3599    IN    TXT    "v=spf1 include:_spf.google.com ~all"
    google.com.        59    IN    SOA    ns1.google.com. dns-admin.google.com. 216967258 900 900 1800 60

Reverse DNS Lookup
To query the hostname associated with a specific IP address use the -x option.

For example, to perform a reverse lookup on you would type:

dig -x +noall +answer

As you can see from the output below the IP address is associated with the hostname wildebeest.gnu.org.

    ; <<>>DiG 9.10.6 <<>> -x +noall +answer
    ;; global options: +cmd 245 IN    PTR    wildebeest.gnu.org.

Bulk Queries
If you want to query a large number of domains, you can add them in a file (one domain per line) and use the -f option followed by the file name.

In the following example, we are querying the domains listed in the domains.txt file.


dig -f domains.txt +short

The .digrc File

The dig command’s behavior can be controlled by setting up per-user options in the ${HOME}/.digrc file.

If the .digrc file is present in the user’s home directory, the options specified in it are applied before the command line arguments.

For example, if you want to display only the answer section, open your text editor and create the following ~/.digrc file:

+nocmd +noall +answer

dig like nslookup is a command-line tool for querying DNS information and troubleshooting DNS related issues. My personal opinion dig is a much more powerful tool since it gives more of the raw DNS output. In the hands of an individual who understands DNS both dig and nslookup are powerful tools.

Magic Candle Company

Disney Park withdrawals?

Click on the image and get 10% off!

Join the EFF

Join the EFF
#privacy #digitalrights