applied security research
Wesley Neelen - 06 aug 2020

Hacking the traffic light of the future

Nowadays we are connecting everything we can think of to the internet. Usually to make our lives easier or more comfortable. Some of the new upcoming innovations are related to making our traffic smart with the goal to improve safety, comfort and the traffic flow. We dived into this technology to analyze the inner workings and identify potential security risks.

TLDR: watch our DEFCON talk on YouTube.

Recently we stumbled upon videos and information that got our attention. In the Netherlands, a project was launched to connect traffic lights to the internet. There were multiple initiatives to do so, started by different vendors in various cities. A use case would be to turn the lights green faster as a vehicle or cyclist approaches. Or allowing emergency vehicles instantly green if their blue light is turned on.

This is already done for decades using physical solutions on the road (“loops”) or by using short range communication (e.g. radio, microwave, infrared), but by incorporating the internet allows for a range of new opportunities and flexibility.  The overall idea of the innovation is to improve the accessibility, traffic flow, traffic safety and quality of life on the road network through real-time information exchange.

When we saw the project for the first time, instantly the question popped up: how does this work and what happens if this would be manipulated by a malicious actor?

After diving into the subject, it appeared that multiple traffic lights, located in the Netherlands, were already connected to the internet. These traffic lights recognize cyclists running a specific app on their phone. After detecting an approaching cyclist, the Traffic Light Controller on the intersection will decrease the time to green if possible.

There are different apps to cover several types of road users, for example:

  • Pedestrians
  • Cyclists
  • Trucks

We decided to continue our research with the cyclist apps because in that domain multiple apps were already publicly accessible to us.

Important note for the people outside of the Netherlands: in the Netherlands we do have a lot cycling infrastructure (about 35.000 kilometres) and about 22.8 million bicycles (which is more than citizens). This results in almost every intersection having traffic lights that are specificly placed for cyclists, which we’ve learned is not so common in other countries. If you’ve ever been to Amsterdam you know cyclists are everywhere: an (environmental) blessing in (chaotic) disguise.

Diving into the first application

One of the first “smart” traffic lights we found was clearly a proof of concept environment: there was even a separate indicative “Cyclist Seen” light showing whether a cyclist with active app was recognized by the system.

We started off by downloading and unpacking the Android application to get insights into the code of the application. The first interesting thing we saw in the application was code indicating that MQTT (Message Queueing Telemetry Transport) was being used. We discovered a server MQTT IP-address, username and password were hardcoded in the apps. So, we concluded MQTT was the protocol our app used to communicate with the traffic lights.

MQTT is a protocol that is widely used in the Internet-of-Things. In a nutshell: it is a lightweight protocol that consists of channels. The MQTT Clients can subscribe and/or publish to these channels, to read or share messages on the channels. For instance, a user of the app would share a message to a certain channel, which a traffic light would be subscribed to and triggered a workflow. We decided to do more in-depth investigation.

ETSI CAM objects

After a while we found the next rabbit-hole: Cooperative Awareness Message (CAM) objects, which were distributed using the MQTT protocol. CAM objects were introduced as part of a standard developed by ETSI to improve data exchange among technology providers.

The CAM standard was specifically developed to share traffic related information. A CAM-object contains a wide range of information about a vehicle, such as:

  • longitude / latitude (GPS location)
  • vehicle type
  • speed
  • lane position
  • siren / light bar status

The CAM objects were sent to the backend system over MQTT. This allows a vehicle to report, in a very detailed way, the properties of itself while passing the traffic light. The nature of CAM objects got us excited: we might be onto something here. The openness of CAM objects allowed us to manipulate a lot of properties describing a vehicle. If the backend system would accept our manipulated CAM objects, unexpected behaviour might occur.

Manipulating the CAM object station type

At this stage we wanted to manipulate the CAM objects and verify whether the backend performs any checks to prevent manipulation. Initially we were trying to connect to the MQTT channel ourselves and craft our own CAM object. However, CAM objects were very specific to the automotive sector and quite exotic (at least unknown to us). We ended up in a rabbit hole, trying to re-use code used by the original app for Android. Our goal was to figure out how to craft CAM objects and encode them in the correct way (protobuf and ASN encoding). It was a terrible experience ;-)…

So, after a while we decided to take another approach. We figured to use the functionality in the app itself to manipulate the CAM objects from there. A great tool to accomplish this is Frida, an incredible powerful tool to hook into (Android) applications. It basically allowed us to hook into the application at a specific point, modify some values and let the application handle the rest.

It was the first time for us using Frida, so it was a great learning adventure. The first attempt we performed was to hook into the application at the correct function in order to view the CAM objects that are being sent by the application. After some trial and error, we successfully hooked into the correct function to print out the current CAM object just before it was sent onto the MQTT channel:

CAM-object content snippet

value basicContainer ::= {
  stationType cyclist,
  referencePosition {
    latitude 51xx,
    longitude 50xx,
    positionConfidenceEllipse {
      semiMajorConfidence unavailable,
      semiMinorConfidence unavailable,
      semiMajorOrientation unavailable
    altitude {
      altitudeValue 4000,
      altitudeConfidence unavailable

We got insights into the CAM object contents. Is it possible to manipulate these contents? We succeeded in writing a script that calls a function that modifies the stationType (which contains the type of road user sending the message), to whatever value we want. For example, in the following CAM object we were able to modify the stationType from our CAM objects from ‘cyclist’ to ‘tram’ just before publishing the CAM object:

Modified the CAM-object

value basicContainer ::= {
  stationType tram,
  referencePosition {
    latitude 515623160,
    longitude 50737430,
    positionConfidenceEllipse {
      semiMajorConfidence unavailable,
      semiMinorConfidence unavailable,
      semiMajorOrientation unavailable
    altitude {
      altitudeValue 4000,
      altitudeConfidence unavailable

So, it was possible to modify the CAM object properties before sending it onto the MQTT channel.

Manipulating the CAM object GPS coordinates

The CAM object contains so many properties to manipulate. One of them which should be easier to debug are the GPS-coordinate properties. After all: the separate “cyclist seen” light we mentioned earlier, could be used to confirm whether the system responded to our input. We created a Frida script that modifies the following properties in the CAM object:

  • longitude
  • latitude
  • speed
  • bearing
  • accuracy
  • altitude

The script keeps on repeating two different GPS coordinates to fake a cyclist that is continuously passing the traffic light.

Two coordinates are required in order to look like a legit cyclist. The system will only respond if a cyclist is actually cycling. By running this script, the cyclist-seen-light turns on one-time, which proofs that the system sees our fake cyclist as a legit one. However, we wanted to trigger as much green as possible, to determine how far we could manipulate the light.

In order to do so, we created another script. During the research we discovered that every new MQTT connection was identified as a new cyclist. So, we created a new script: that just reconnects every time just before publishing our CAM object :-). We were hoping that the backend would see the following behaviour:

At the traffic light location, we could verify that the thing we expected occurred 🙂

By running both scripts, we emulate a continuously ongoing flow of cyclist passing the traffic light. This results in the actual traffic light controller to decrease the waiting time to green as much as it is allowed to. The behaviour that we trigger can be compared with a person pushing the physical button located at the traffic light all the time. The safety systems stay intact. So if the cyclists light turns green, the other lights (e.g. car lights), will be red and vice versa.

Diving into the second application

Later we found another project with traffic lights connected in 10 municipalities. An application was publicly available, so we were able to download and investigate it. This application was easier to investigate: we were able to configure an Android phone with the application proxying all of its request through our Burp proxy. This allowed us to see all the HTTPS connections that were sent to a cloud service.

We found out that the actual requests being sent by the application were quite simple. Information was sent to the cloud service using a POST-request. The POST-request contained data similar to this:

POST-request example


As seen in above POST data, the application sends information such as speed, heading and GPS-coordinates to the cloud server. After debugging at a actual connected traffic light, we discovered the following:

  • Just one HTTP request was enough to influence the traffic light;
  • No authentication was required;
  • No way to distinguish different cyclists from each other was available (a unique identifier or something like that).

We were able to convert our findings in an exploit, a Python scripts that sends one POST request to the cloud service. By running the script, the following behaviour occurs at the traffic light:

  • if there is other traffic at the intersection: it decreases time to green of the cyclists light
  • if there is no traffic at the intersection: it instantly turns green

In order to show above situations, we recorded two demo’s:


We found something interesting in both implementations. Both platforms are not really able to distinguish the cyclists from each other. One application is seeing every MQTT connection as a new cyclist, the other one is seeing every new HTTP connection as a new cyclist.

That is an interesting fact: this allows us to imitate a lot of cyclist at once. Imagine: just request all the cycling traffic lights in a city to turn green continuously in a loop. That would result in the cyclist light turning green as much as the local traffic light system / configuration allows it to. Whenever the cyclist light is turned green, the other traffic will get a red light. This will be quite annoying for the other road users.

In order to show how this could look like while attacking many traffic lights in a city, we created the following fictional visualization:

Luckily that’s the current impact: annoying. Two lights will never turn green simultaneously. The built-in security system prevents this to happen. On the other hand we can influence the traffic flow (one of the goals of smart traffic) in a negative way, letting a lot of people wait for nothing. Or let them stop all the time for no reason. And by talking to people involved we did understand that annoyed road users are dangerous road users, so there does seem to be an indirect safety impact.


Our proof of concepts allow us to remotely influence the affected traffic light systems. From any remote location, we can simulate cyclists approaching, causing the system to decrease the time to green (or even get instant green). Currently, this attack could be performed on traffic lights in about 10 municipalities.

The current findings are limited to the cycling traffic lights. This does have an effect on the car lights, it will turn them red whenever the cyclist light goes green, but we cannot do it the other way around yet with the current implementations.

We investigated the standards being used. These standards describe and support security measurements to prevent our findings. For example, the CAM standard supports signing. In the real life implementations we investigated, these standards are not or not used correctly.

The consequences of these kinds of attack would be bigger if an attacker succeeds to use the same trick to influence the car traffic lights or even simulate emergency vehicles (instant green). This would have a much greater impact on the regular traffic flow: just consider how car drivers respond now to an ambulance approaching.

It is a really cool innovation that’s going on. Smart traffic lights to increase the usability of the traffic light system. However, we really have to build these systems with security in mind. These systems can directly impact people’s lives. At Zolder we get excited by these kinds of innovations. We believe the innovations are both important as well as inevitable. We just need to figure out how to do this safely. We performed this investigation to create some awareness on this topic. However, finding the correct solution is not that easy, because in the end we do have to trust input from road participants.

At Zolder we believe these innovations are on one hand generally beneficial to society and on the other hand simply unavoidable and that the amount will rapidly increase the upcoming years. We reported our findings to both developers so they could fix the issues in their implementations. With sharing our findings at the DEF CON conference we hope to inspire others to contribute to a safer smart traffic future.


Attic versie 2023.9.0 - Release Notes

- 21 sep 2023
Een nieuwe Attic #release bomvol nieuwe checks, geïnspireerd door de #CIS Benchmark voor #Microsoft365. Deze release zit vol met nieuwe Checks en Fixes. Want we zijn hard bezig om te zorgen dat Attic “CIS-certified” raakt als assessment tool voor Microsoft365 en hebben nu bijna alle checks gebouwd die daarvoor nog nodig waren. Daarnaast is er […] Lees verder

Microsoft Sentinel: Wapen tegen Cyberdreigingen

Erik Remmelzwaal - 19 sep 2023
In de wereld van cybersecurity sta je voor een belangrijke uitdaging: het beschermen van je organisatie tegen digitale bedreigingen. Gelukkig is er een krachtig hulpmiddel tot je beschikking: Microsoft Sentinel. Wij praten er veel over vanwege onze dienstverlening, maar wat is het nu eigenlijk? in dit blog deel ik graag mijn inzichten met jou, zodat je een solide basisbegrip krijgt van wat dit product is en hoe je het kunt inzetten. Lees verder

Door NIS2 moet je iets gaan doen wat je nu nog niet doet...

Erik Remmelzwaal - 03 aug 2023
Als je onder een steen hebt geleefd: NIS2 komt eraan. De 2e versie van de Network and Information Security richtlijn van de EU. Het duurt nog even voordat dit in Nederlandse wetgeving is omgezet en daarin kunnen nog belangrijke details gaan schuiven, maar in grote lijnen weten we wat er op ons af komt. Door […] Lees verder

5 tips voor MKB'ers om zichzelf weerbaar te  maken tegen misleiding via internet

- 21 jul 2023
In de digitale wereld worden MKB’ers steeds vaker geconfronteerd met de dreiging van social engineering. In deze blogpost delen we waardevolle inzichten over twee veelvoorkomende vormen van social engineering, phishing en CEO-fraude. We benadrukken echter de praktische tips die MKB’ers kunnen volgen om zichzelf effectief te beschermen tegen deze cyberdreigingen. Phishing en CEO-fraude Phishing omvat […] Lees verder

Using MiTMProxy as a scriptable pre-proxy for BurpSuite

Rik van Duijn - 11 jul 2023
TLDR: you can use mitmproxy to modify stuff before it sent to Burp Proxy. Instruction below. Recently we were asked to asses a oldschool Java client server application. After configuring BurpSuite as a proxy and trusting the CA cert, we noticed the client communication still gave an error. It turned out the client and server […] Lees verder

Wat leren we uit het NCTV Cybersecuritybeeld en Verizon DBIR 2023

Zolder B.V. - 04 jul 2023
De samengestelde conclusie die ik haal uit CSBN en DBIR is dat organisaties (nog steeds) vooral slachtoffer worden via gelekte inloggegevens en e-mail en dat ze datalekken bijna altijd kunnen voorkomen door het implementeren van basismaatregelen. En de basismaatregel die past bij gelekte inloggegevens is Multi-Factor Authentication (MFA). Lees verder

Weerbaar tegen CEO-Fraude met Logs in Microsoft365

Erik Remmelzwaal - 22 jun 2023
Veel organisaties kunnen maar 7 dagen terugkijken in hun Microsoft365 logboeken. Veel te weinig, om adequaat te reageren op incidenten zoals CEO-Fraude en Ransomware. Belangrijk dus om te begrijpen welke mogelijkheden er zijn om die termijn uit te breiden. Lees verder

Attic voor de zorg: De toekomst van beveiliging met partnerschap Z-CERT

- 06 jun 2023
Attic voor de zorg is momenteel in ontwikkeling. We richten ons vooral op de toekomstige beschikbaarheid van deze krachtige beveiligingsoplossing en we nodigen zorginstellingen uit om deel te nemen aan onze beta-testfase. Partnerschap met Z-CERT In samenwerking met Z-CERT, de toonaangevende leverancier van dreigingsinformatie in de Nederlandse zorgsector, biedt Attic voor de zorg een unieke […] Lees verder

Verbeteringen in API's en toekomstige wijzigingen bij Attic

- 24 mei 2023
Microsoft heeft recentelijk enkele verbeteringen doorgevoerd in de API’s die toegang verlenen tot uw tenant. GDAP Op dit moment maakt Attic gebruik van DAP, oftewel Delegated Admin Privileges, om toegang te verkrijgen tot uw omgeving. Microsoft heeft onlangs een verbeterde versie van deze functionaliteit geïntroduceerd, genaamd GDAP, oftewel granular delegated admin privileges. Deze nieuwe versie […] Lees verder

Attic voegt website clone monitor toe

Wesley Neelen - 08 mei 2023
Attic is een krachtig platform wat heel veel mogelijkheden biedt. Attic is modulair opgebouwd zodat het platform aangevuld kan worden met extra diensten, ontwikkeld door Zolder, maar in de toekomst ook door externe leveranciers. Enkele maanden geleden heb ik een gratis applicatie gelanceerd genaamd Deze service is gebaseerd op Microsoft Azure en volledig cloud […] Lees verder

Attic als SOC

Zolder B.V. - 11 apr 2023
Bijna is het zover: roadmap-technisch naderen we het punt dat we de koppeling van Attic met Microsoft Sentinel gaan afronden. En daarmee de gelegenheid om op grote schaal organisaties te voorzien van een betaalbare SOC dienst. Tijdens onze deelname aan de RSA conferentie zullen we bezoekers van onze stand en website aanbieden zich alvast te […] Lees verder

Internetoplichters richten pijlen op Hockeyvereniging

Erik Remmelzwaal - 10 mrt 2023
De penningmeester van Hockeyclub Zevenbergen ontving een poging tot oplichting. Gelukkig werd het herkend, maar zal dat overal gebeuren, nu internetoplichters hun pijlen blijkbaar op sportverenigingen hebben gericht? Lees verder

Microsoft Digital Defense Report

Erik Remmelzwaal - 14 nov 2022
Het Digital Defense Report 2022 van Microsoft is uitgekomen. Wat zijn de highlights en key takeaways? Lees verder

TBX2022 Throwback & Masterclass

Erik Remmelzwaal - 07 nov 2022
Op 2 en 3 november vond in de Jaarbeurs Utrecht de TBX2022 beurs plaats. Zolder was net als vorig jaar aanwezig als exposant, en was op beide dagen de host van een masterclass. Ons voornaamste doel was om ons nieuwe propositie van Attic for MSPs bekend te maken. Met deze nieuwe release, stellen we andere […] Lees verder

Hacking my Helium Crypto Miner

Wesley Neelen - 05 sep 2022
Recently I came across an interesting cryptocurrency project called Helium. Its a wireless network built by people all around the world. The people that help expanding the network by adding a hotspot receive the Helium cryptocurrency coin by providing the coverage. During my research I decided to order one of those Helium miners. I ordered […] Lees verder

PEN-300 / OSEP review

Wesley Neelen - 19 jul 2022
This year I decided to start a new study, the PEN-300 course of Offensive Security. In 2012 I did the OSCP course and in 2013 OSCE. In 2016 I took the OSEE class in Vegas, unfortunately never took the exam (one of my biggest mistakes ever🥴). I liked all the courses very much at that […] Lees verder

Deze 3 misverstanden blokkeren het ontwikkelen van cyberweerbaarheid

Zolder B.V. - 04 jul 2022
Het NCTV heeft weer het jaarlijkse Cybersecuritybeeld Nederland gepubliceerd. Het CSBN-2022. Mooie aanleiding om eens op te schrijven waar ik al langer mee in mijn hoofd zit. Drie hardnekkige en foute aannames die mensen hebben bij digitale dreigingen. Drie misverstanden dus, die in mijn ervaring de belangrijkste reden zijn dat we nauwelijks vooruit komen met […] Lees verder

Cyberweerbaarheid en Operational Technology

Erik Remmelzwaal - 02 jun 2022
Onlangs nam Erik Remmelzwaal, co-owner en Managing Director van Zolder BV, deel aan een tafelgesprek van Data Value Center – Smart Industry (DVC-SI). Het thema was Cyberweerbaarheid en Operational Technology, en het gesprek werd opgenomen in de campus van Breda Robotics, waar Zolder lid van is. De opname is inmiddels beschikbaar en terug te kijken […] Lees verder

Detecting MFASweep using Azure Sentinel

Zolder B.V. - 01 nov 2021
Many companies are using cloud services such as Microsoft 365 for email, file sharing and communicating. If an attacker gains access to valid credentials that allows them to authenticate to the account, all information within the account is usually instantly accessible. Therefor, implementing multi factor authentication is one of the most important steps while securing […] Lees verder

Public SharePoint sites - the new open shares

Wesley Neelen - 16 sep 2021
During one of our engagements we were investigating a Microsoft 365 environment. My colleague Rik discovered that many SharePoint sites were publicly available within the organization. We were surprised by the amount sites that were wide open this way. A lot of sensitive information was located on those sites, for example PII-information and passwords for […] Lees verder