A Tale of Creating a Cell Phone Tracker
Our First Hackathon
Sometime in mid-June of 2020, Elastic invited my organization to participate in a hackathon they were hosting. For those that don’t know, Elastic is a pretty big up and comer in the Search space and described at times as the next Google. Those are some big shoes to fill, but that’s a discussion for another time.
My organization’s primary business is in cybersecurity, and Elastic has been making moves into that industry, hoping to use it’s search tools to empower threat hunters and allow them to digest, analyze, and correlate events happening across the enterprise. They already have an out-of-box SIEM solution to rival the likes of Splunk. All of which brings us full circle back to the hackathon. Elastic wanted to see how it’s users could push the platform to build and do exciting things.
The rules were an organization had to submit up to a four-person team (we submitted three), and you couldn’t use any proprietary data or algorithms. It was a week and a half long, we could use any datasets, and had a trial license that gave all the premium features of paying customers. The biggest obstacle out the gate was us. We work in cybersecurity. We hunt APTs, consume intel feeds, and tune IDS alerts. We don’t engineer platforms, write program applications, or establish APIs. If anything, in our field, breaking a system is more valuable than building it.
We set out to brainstorm on ideas on how we could best utilize an Elastic Stack in a way not intended for security. They already had a SIEM, and with the acquisition of host-based protection industry leader, Endgame, their suite of tools has grown more comprehensive. What else is there? A member of my team, John, had the idea for wireless.
But Really? Wireless?
Yes! And at first, I was just as skeptical. Typically in an enterprise network, wireless sits at the edge, and most of the protections lie upon connecting to a wireless access point…assuming your organization protects wireless. Of course, John wasn’t just talking about good old fashion WiFi. He wanted to expand to cover all RF protocols and frequencies, and this was a good idea. These items are becoming more prevalent with the increase of IoT devices, and visibility into the inner workings will soon be a necessity. Now, I mentioned our lack of experience with actually building things, but we were also on a time constraint (still had our day jobs and families), and no budget. We decided just to set up a couple of Raspberry Pis, capture local WiFi, and hope inspiration struck again.
Note: For our wireless captures, we used two Raspberry Pi model 4b’s running Kali Linux (Link if you want to get one yourself). We went with the model 4b’s because these were the first Raspberry Pis with the ability to capture WiFi in promiscuous mode, without needing an external adapter. If you don’t have model 4b, here is an adapter I highly recommend that works up to 802.11ac. (Disclosure: I get commissions for purchases made through links in this post.)
First Impressions
We started with simple things first. Capturing all traffic in the air and quickly running out of space on our modest SD cards mounted into the Pi. Again our first issue coalesced itself. The bulk of our capture traffic was just the same as if we had captured it over the wire…standard and boring TCP/UDP packets. Nothing the prebuilt SIEM couldn’t handle. Eventually, we decided to discard what most analysts would consider the relevant parts and focused solely on the 802.11 control traffic. Here is where things got interesting. We were getting capturing all the beacons and probes around us.
Quick Background on Beacons and Probes: Typically, WiFi access points will beacon, or send out, their Service Set Identifier (SSID). The SSID is essentially the name of the WiFi access point. Unless this were disabled, that access point would continuously advertise itself out there for devices to connect. Let’s say you were grabbing coffee, and you connected to the access point beaconing ‘Starbucks-WiFi.’ After successfully connecting to an SSID, your device will routinely probe the air looking for that access point. Go ahead and open up your saved wireless networks. For the most part, your device is regularly sending out frames seeing if that WiFi is around. All those probes and beacons can be captured and analyzed.
Still Figuring Everything Out
By this point, we were 3–4 days into the project. We had set up an Elastic Stack, narrowed down what we were capturing to WiFi probes, and had figured out how to ingest all that data into Elastic. The main showing point for the hackathon was dashboards, so we started putting together some very basic visualizations.
In this dashboard, we could chart our 2.4 GHz and 5 GHz frequencies, all the probes for SSIDs, info on wireless chip manufactures, and even the most commonly used wireless channels.
Lightning Does Strike Twice
And here is where inspiration rears it’s beautiful head once more. Through fiddling with display filters in Kibana, we found out we could profile devices by the SSID probes and signal strength among a few characteristics.
This process was still unrefined and almost entirely manual, but it was still an exciting discovery. If malicious traffic could be identified on a network, using what my team had put together, it was possible to uncover the devices’ physical makeups.
I Don’t Just Want To Know About The Device…I want to see it.
Personally, I liked the concept of attack maps. It took something that happened in the abstract cyber realm and showed me physically where that attack happened or where it was going. I wanted to do something similar, and I set out to use what data we had collected to accomplish it.
On the last day before our project had to be submitted, I finally figured out how to use the Map visualizations in the Elastic Stack(would you believe there is standard for GeoJson formats?). Using signal strength collected from our Raspberry Pis, we could specify a particular device probe and correlate it to GPS coordinates. Not just a single location, mind you. We were able to track that device’s movement over time while it remained in the range of our wireless sensors.
Disclaimer: We only had two Pis collecting probes, so our positional detection and tracking was flawed. If we knew our work was taking us in this direction, we would have set up two more Pis to create a more accurate positioning system.
Ethics? What is that?
This was definitely a watershed moment for our team. We were proud of what we had accomplished, but at the same time, we were troubled by just how easy, inexpensive, scalable, and privacy-invading this could be. If three log analysts could put this together in one week, what could dedicated engineers with a budget and an agenda accomplish?
We carried these concerns forward when we presented our project to Elastic. Ultimately, what my team members and I had done, was exactly what they were looking for, and the folks at Elastic were happy by what we came up with. Overall we placed 2nd in the competition. Might have got 1st if we had a third Pi.
Want more?
I’m currently compiling notes and the code we used to build our system. I’ll throw up a link to GitHub in the future. If you’re interested on how to setup your own Elastic Stack, check my previous article: Indexing Network Traffic with Moloch and Elastic
