Back in December 2024, I wrote about macvendors.co.uk, a small tool I had put together for looking up the registered vendor behind a MAC address. The main reason for building it was fairly simple: I wanted to paste in a large list of addresses, get useful results back, and download them as a CSV.

The original single-address lookup and bulk lookup are both still there, but quite a lot has changed behind them since that first post.

More complete IEEE data

The first version worked with the familiar 24-bit OUI prefix: the first six hexadecimal characters of a MAC address. That remains useful, but it is no longer the whole picture.

The lookup database now includes the IEEE’s 24-bit MA-L assignments, 28-bit MA-M assignments and 36-bit MA-S assignments. When an address is entered, the site checks the most specific matching assignment first. This matters because a smaller block can be registered to a different organisation within a larger allocation, and looking at only the first six characters can therefore produce a less precise answer.

At the time of writing, the site holds more than 54,000 IEEE assignments covering over 30,000 distinct registry organisation names. The source data is refreshed automatically from the IEEE Registration Authority, and the date and current record totals are shown on the site rather than hidden away in the background. There is also a new data sources page explaining exactly which registries are used.

Better handling of private and randomised addresses

Modern phones, laptops, virtual machines and other devices often use locally administered MAC addresses. Wi-Fi address randomisation is probably the example most people will encounter.

These addresses cannot reliably identify the manufacturer from their prefix, so the lookup now checks the universal/local bit and reports Locally administered where appropriate. That is a more useful answer than presenting an accidental prefix match as if it identified the hardware.

The new lookup methodology page explains this process, including the difference between the local bit and the separate multicast bit. It also explains an important limitation: a registry result tells you which organisation holds an assignment, but it does not prove the model, owner or current operator of a device.

A more useful bulk lookup

The bulk MAC address lookup now accepts up to 1,000 addresses at a time. You do not have to clean the input into a neat list first: it can extract recognised MAC addresses from pasted text such as show arp, show mac-address table and show ethernet-switching table output.

Results can still be downloaded as CSV, which was the feature that prompted me to build the site in the first place.

Browse the registry as well as searching it

There is now a searchable vendor directory. It lists registered organisations and lets you open a vendor to see its MA-L, MA-M and MA-S assignments. Individual prefix pages show the assignment type, prefix length and registered organisation.

This is handy when you know the company name and want to inspect its allocations, rather than starting with a complete MAC address. It is also a good illustration of why one company may appear under several related or historic registry names.

New practical guides

A vendor name is usually only one clue in identifying something on a network, so I have added a small MAC address and OUI guides section. It currently covers:

• how to identify a device by combining a vendor result with switch, ARP, DHCP, Wi-Fi and inventory data;
• the difference between OUI, MA-L, MA-M and MA-S assignments;
• locally administered and multicast address bits; and
• working with MAC addresses found in switch, ARP and DHCP output.

The aim is to explain what the result actually means and how to use it without claiming that a prefix alone can identify an exact device.

The API is still in the same place

The public MAC address lookup API remains available at:

https://macvendors.co.uk/api/mac_lookup/<mac_address>

Existing clients do not need to change their URL or the JSON response they expect. Behind the scenes, the API now keeps the lookup registry in memory and runs separately from the public web interface. That gives both parts of the service more room to handle busy periods without changing how the API is used.

The documentation now includes command-line, Python and PowerShell examples, along with a downloadable OpenAPI 3.1 description for tooling which can consume it.

Fair-use protection is also in place so that an unusually heavy client is less likely to affect everyone else. If the service asks a client to slow down, it returns the standard HTTP 429 Too Many Requests response.

The original idea has not changed: paste in a MAC address, or a great heap of them, and get a useful answer without any fuss. The site now has fresher and more complete source data, handles modern address behaviour more honestly, and provides a few more ways to explore and understand the results.

Have a look at macvendors.co.uk and, as ever, enjoy!

Don’t open THAT attachment!!

I run a mail service for a number of friends, mainly personal, but some business. Part of the service configuration blocks attachments which are sent where the file is a specific extension (for example exe, com, bat, scr, vbs, etc). Over the last few years, it’s done a great job in filtering out malicious stuff, but of late, I’ve started pushing the files into an Open Source sandbox called Cuckoo, for extra protection, but also the nerd factor as this sort of thing interests me, Sandboxes are great, as they allow you to execute an unknown file in a restricted environment, then view the results without it ever affecting your actual computer. Once you have the results, you can decide whether it’s safe or not. So what follows should be considered a warning – ‘Don’t open THAT attachment!’.

First off, here’s the mail alert –

 

It actually looks like it’s come from a valid source, but if you look closer, you’ll see then the actual sender is IP 192.3.10.7 (owned by Colo-Crossing). Hmmmm….never-mind, we’ll push forward and take a peak at the file anyway. The actual file attachment in the mail is called ‘Hello.zip’, inside it are two files; a Word file, and a VBS script.

Files which are blocked are stored in a special mailbox for me to review. These files are uploaded to the Cuckoo Sandbox using a browser (no, I don’t use Windows to do this!) which is protected from running unknown scripts. Once the file is loaded, the sandbox executes it. I’ve ignored the Word file in the attachment, and instead gone straight to the VBS script. After a few minutes, the results are in –

 

Uh oh, a score of 11.2 out of 10 (I guess it does say the score feature is in Alpha on Cuckoo :P), I’m already suspicious. Lets see what this VBS script does.

First off, it’s queried the computer name, asked about system information, queried which browsers are installed, and checked how much memory is available.

Thats suspicious, but not actually ‘doing’ anything to the system.

Next, we see the script starting to do something.

Whoa!! Now we’re getting somewhere. There’s quite a lot of things happening here, but the one which springs out to me more than any other is ‘File has been identified by one AntiVirus engine on VirusTotal’. VirusTotal, can check up to 56 AntiVirus engines, so being detected by only ONE is a serious issue. Think your local AV is going to protect you? Think again. Local AV is the last, and often worst line of defence. The script also initiates a number of outbound HTTP requests, and steals a lot of information from local browsers, as well as creating additional processes. Very scary!.

Finally, we see the real damage of the VBS script.

The VBS script now starts to do some credential stealing. Email, FTP, IM Client credentials amongst other nefarious actions, are raked from the machine. Add these to the fact it’s created a new process which is running on the computer (and will run at system startup), the computer is now something to run away from. All from opening an attachment from an unknown source.

Don’t open attachments from emails when you don’t recognise the source!

CDS Group Email/Malicious Attachments

Over recent days, my mail relay has been receiving repeated email spam/malicious attachments to various accounts where the ‘from’ address claims to be ‘accounts@cdsgroup.co.uk’. CDS Group is a Courier Business operating in the UK. The emails contain zip files, and in-turn, the zip file contains a malicious xls.scr file which can cause nastiness on your PC. More information on CDS Group Email can be seen on the excellent Dynamoo Blog.

Here, from my mail logs is one such attempt.

Banned name: .exe,invoice_cdsgroup_799543.xls/invoice_cdsgroup_799543.xls.scr
Content type: Banned
Internal reference code for the message is 22915-03/KkviimjUhz4l
First upstream SMTP client IP address: [202.43.74.182]
According to a 'Received:' trace, the message apparently originated at:
 [202.43.74.182], [202.43.74.182] unknown [202.43.74.182]
Return-Path: <accounts@cdsgroup.co.uk>
From: "Kris Haley CDS Group" <accounts@cdsgroup.co.uk>
Message-ID: <20140807180922.A9A8119A8F8E354F@cdsgroup.co.uk>
Subject: CDS Invoice: 412-96221
The message has been quarantined as: banned@unimatrixzero.co.uk

CDS Group as far as I can tell don’t operate in Indonesia which is where the originating IP is from –

inetnum:        202.43.72.0 - 202.43.75.255
netname:        INTERLINK-TECH-ID
descr:          PT. INTERLINK TECHNOLOGY
descr:          Internet Service Provider
descr:          Cyber Data Centre 5th Floor
descr:          Cyber Building.
descr:          Jl. Kuningan Barat no. 8
descr:          Jakarta Selatan, 12710
country:        ID

So, CDS Group are completely innocent in this case, and I feel sorry for them. It’s a trivial matter to fake the ‘from’ address on an email, anyone can do it. Fortunately, they’ve now deleted the ‘accounts’ email alias on their domain, so anything claiming to be from that address is invalid.

It’s also a trivial matter to block emails claiming to be from ‘accounts@cdsgroup.co.uk’. I use Postfix as my mail relay software, and have added the following line to a ‘sender_access’ DB file which blocks email matching certain conditions.

accounts@cdsgroup.co.uk     REJECT May your shit come to life and kiss you

As the SMTP 550 response says ‘May your shit come to life and kiss you’ (quoting the awesomeness of Frank Zappa).

WordPress XMLRPC Attacks

Fun going down today on the web. My webserver is being hit by multiple IP attempts to POST data to xmlrpc.php which comes as part of the WordPress installation and is used for PingBack Vulnerability exploits to DDoS other WordPress sites. Thousands of individual IP addresses are attempting to ‘POST /xmlrpc.php HTTP/1.1’.

It’s been happening since around 0400 this morning (GMT).

A quick shell script to gather data from the access log shows 3741 unique IP addresses (and counting) attempting to send the following command to the webserver.

POST /xmlrpc.php HTTP/1.1

The shell script is as follows –

#!/bin/sh
cd /var/log/apache2/
cat access.log | grep "POST /xmlrpc.php HTTP/1.1" | ipsort -au | wc -l
cat access.log | grep "POST /xmlrpc.php HTTP/1.1" | ipsort -au > xmlrpc_attackers.txt
exit 0

I’m doing a count of the access log file after searching for the relevant line on line 3 of the script, and the same command (except exporting the output to a text file) on line 4 of the script. The line 4 command is for some forensic investigations later although it’s possible/likely a lot of the IP addresses attempting to connect are members (un-whitingly) of a Botnet. The ipsort command from JimSun’s website helps to filter and show unique IP addresses.

Nothing has managed to get in so far, fortunately.

The POST request contains the following data –

POST /xmlrpc.php HTTP/1.1
Connection: Close
Content-Length: 215
Host: andymillett.co.uk
<?xml version="1.0" encoding="iso-8859-1"?>
<methodCall>
<methodName>wp.getUsersBlogs</methodName>
<params>
<param><value>test</value></param>
<param><value>427900</value></param>
</params>
</methodCall>

The <value></value> changes with every connecting IP, but everything else remains the same.

NTOPNG Network Flow Monitoring

I’ve used open-source network flow monitoring software for a long time now. Sflow/Netflow/JFlow applications are a nice way of getting visibility of network throughput at ingress/egress points of your network, as are SPAN/TAP devices which simply listen on a mirror port. NTOP has been around for some years, is a great application for doing this and has recently under gone a lot of development to bring us NTOPNG. It also offers a low-cost alternative to full Layer 7 inspection devices although it doesn’t necessarily have the full detection depth of such commercial products (appliances such as Allot’s NetEnforcer, or Blue Coat’s Packetshaper).

NTOPNG is available as a source package which you can build yourself as well as pre-built binaries (some Linux OSes come with it packaged) all the way up to commercial appliances capable of monitoring flows at very high speeds. For my purposes, I used the source package, with the intention of building a Virtual Machine capable of monitoring the network and have a mirror port on my switch.

My VM settings are pretty basic – 1GB memory, 20GB disk space, and two vNIC’s. I used Debian as my OS of choice for the VM. A basic install was needed to begin with, with a few extra packages needed later to support the installation of NTOPNG (more on that below).

Network adapter 1 is for management, adapter 2 is for packet capturing from the switch mirror port. The mirror port uses a spare physical NIC on the ESX host which is configured in promiscuous mode (e.g it hears everything).

I won’t go into the basic install of Debian here, however, to build ntopng, you will need the following additional packages from the Debian APT sources repository –

apt-get install rrdtool libxml2 wget curl tcpdump libpcap-dev linux-headers-3.2.0-4-amd64 subversion libxml2-dev libglib2.0-0 libglib2.0-dev redis-server

When the above packages have been installed, you can that move forward with the NTOPNG installation.

First, download the two packages from the NTOP website. The files are (at time of writing) –

ntopng-1.1_6932.tgz – NTOPNG main source package

ntopng-data-1.1_6932.tgz – NTOPNG GEOIP data.

Place the files somewhere accessible on your VM (I use the /root directory). You’ll need to untar the ‘ntopng-1.1_6932.tgz’ file in the normal manner (e.g ‘tar xzvf ntopng-1.1_6932.tgz’). Once extracted, cd into the newly created ntopng directory

cd ntopng-1.1_6932

Now start building the package by entering the following command

./configure

If all is well and you have the necessary supporting packages installed (as mentioned above), the output after this command has executed should read –

You are now ready to compile typing make

Enter ‘make’ to start building ntopng. The VM will start to build ntopng and may take a few minutes depending on the speed of the CPU and how busy the ESX host is. When it is finished, you will simply be returned to a command prompt if the build was successful.

Next, enter the following command to install ntopng onto your Linux host.

make install

Once done, you can fire up ntopng. There are a number of parameters which can be specified with the ntopng command.

Usage:
 ntopng <configuration file>
 or
 ntopng [-m <local nets>] [-d <data dir>] [-e] [-g <core>] [-n mode] [-i <iface|pcap file>]
 [-w <http port>] [-p <protos>] [-P] [-d <path>]
 [-c <categorization key>] [-r <redis>]
 [-l] [-U <sys user>] [-s] [-v] [-C]
 [-B <filter>] [-A <mode>]

My command line is specified as follows –

/usr/local/bin/ntopng -i eth1 -m "172.16.17.0/28, 172.16.129.0/24, 172.16.100.0/24, 192.168.17.0/24, 10.23.1.0/24, 10.22.1.0/24. 10.21.1.0/24, 10.20.1.0/24, 172.16.96.0/24" -n 0 -e -l

The above command actually runs from the /etc/rc.local file which is invoked at system startup. This means you don’t need to build a startup script for use in /etc/init.d/ with Debian, as rc.local is already called.

I found the login timeout for the web console annoyingly short, so disable logons (with the ‘-l’ switch) as ntopng is on a protected network segment.

With all that done, here are some screen captures from ntopng. First off, live traffic.

Top Talkers

Top Hosts

Active Flows

Flow Detail

Next, we can view historical data from ntopng (this is based on information since the process started up).

Interface History

Protocol History

SPAN/TAP configuration

For the switch mirror end of the setup, I configured my Juniper EX2200C to mirror the ingress/egress port (ge-0/0/9) to the physical NIC which vSwitch1 is attached too (ge-0/0/10). This then maps the mirror port to the PCAP vNIC which is assigned to the Debian VM.

set ethernet-switching-options analyzer SESSION1 input ingress interface ge-0/0/9.0
set ethernet-switching-options analyzer SESSION1 input egress interface ge-0/0/9.0
set ethernet-switching-options analyzer SESSION1 output interface ge-0/0/10.0
set ethernet-switching-options storm-control interface all

Conclusion

So there you have it. NTOPNG setup and nicely monitoring my network. There are lots of other features to play with, including integration with block.si for URL Category monitoring which I may play with in the future.