So often when we're working an incident on the network side, we quickly end up at Layer 2, working with MAC Addresses.
MAC addresses are 48 bit (6 bytes, or 12 hex characters) values, and are commonly split by a colons, dashes or dots (all are equally valid):

aa:bb:cc:dd:ee:ff
aa-bb-cc-dd-ee-ff
aabbcc-ddeeff
aabb.ccdd.eeff

MAC addresses are commonly split, with the leading bits being the OUI (Organizationally Unique Identifier).  These OUI's (also called MAC Address Prefixes) are purchased from the IEEE (at https://standards.ieee.org/products-services/regauth/oui/index.html).  The most commonly seen OUI's are 24 bits wide, so the first 3 bytes of the MAC.  So in our example above, the corresponding 24 bit OUI would be: aabbcc, and the host "bits" would be ddeeff.  However, that "OUI boundary" can move to a 28 or 36 byte boundary, for instance if the vendor wants a smaller allocation of addresss.  In that case, OUIs of aabbccd00000/28 or aabbccdde000/36 would both also be valid identifiers.  Note that if the boundary isn't at the mid-point, that the trailing zero's and the bit-wise mask are normally written out.

All interesting you say, but what does this have to do with security?  All too often when looking at MAC address tables, we see something "odd", and it struck me that it'd be handy to have a quick lookup tool.  Wireshark maintains a very most complete online tool (https://www.wireshark.org/tools/oui-lookup.html ), and is usually my go-to.  However, it means that I need internet access, it's not easy to script using a webpage, and on most of my hardware I need to scroll up and down to use that page.  Luckily they maintain their OUI Table in text format at  https://standards.ieee.org/products-services/regauth/oui/index.html

So with a text file in hand, I wrote a quick-and-dirty shell script to download the file it if it isn't there, and grep it for OUI's, partial OUI's or vendor names:

For instance, what OUI's does VMware use for it's VMs?

root@kali:~# ./oui.sh vmware
000569  Vmware  VMware, Inc.
000C29  Vmware  VMware, Inc.
001C14  Vmware  VMware, Inc.
005056  Vmware  VMware, Inc.

Alternatively, if we were looking up an OUI that we got from a switch "show mac address-table" command:

root@kali:~# ./oui.sh 0050:56
005056  Vmware  VMware, Inc.

Or, if you want a list of all vendors that have smaller allocations, let's list the folks with /28's:

root@kali:~# ./oui.sh /28 | more
0055DA000000/28 ShinkoTe        Shinko Technos co.,ltd.
0055DA100000/28 Koolpos KoolPOS Inc.
0055DA200000/28 BeijingC        Beijing Connected Information Technology Co.,Ltd.
0055DA300000/28 NovexxSo        Novexx Solutions GmbH
0055DA400000/28 Datapath        Datapath Limited
0055DA500000/28 Nanoleaf
.....

This script, plus a Windows equivalent cmd file is in my github at: https://github.com/robvandenbrink/ouilookup

Notes:

The Windows version uses c:\utils for the downloaded text file.  I usually keep the script in the same place, but it can really reside anyplace in the path.
The Linux version downloads the text file to $HOME/Downloads, the script can reside anywhere

Edit the script you are using if these directories are not desirable in your situation.

Syntax:

     OUI NN:NN:NN      Request information on a specific OUI
                       Input is NOT case sensitive
                       Acceptable delimiters include ":", "." or "-"
                       Address delimeters can be in any position (at the byte or word boundaries for instance)
                       Address delimeters are optional, and can be partially specified
                       So any of 005000, 00:50:00, 0050.00, 00-50-00 and just 50 are acceptable inputs
    OUI Manufacturer   List all OUI's associated with a manufacturer
                       Partial company names are acceptable
                       Input is NOT case sensitive
    OUI update         Update the OUI listing
                       This update comes from Wireshark's consolidated vendor list (as noted above)

If you've worked an incident where MAC / OUI information was crucial in getting to a solution, please, share using our comment form! (please stay within your NDA of course).

Stay tuned, in my next story we'll use this approach to find "odd" stations in your network.

===============
Rob VandenBrink
rob <at> coherentsecurity.com