My First ATM Pentest (And What I Found)

TD;LR

yo bro! honestly, i’ve been meaning to write this one up for a while. throughout my career, i’ve only done an atm pentest project exactly once. so yeah, most of the findings i got mostly followed the standard checklist from the vendor i was working for at the time. not gonna lie, sometimes i feel like some of the findings are a bit wild or i wouldn’t have thought of them natively, so this project was purely based on raw experience.

let’s set the stage. there’s a bank in indonesia, a client of the vendor i was at. at that time, they were going through a pci-dss audit. because the rest of my team and colleagues were completely slammed with other projects, and i happened to have an open slot, my lead told me and a buddy to handle this gig together onsite at the bank.

before d-day, i did my homework. i pulled a bunch of references (which i’ll drop at the end of this post) and old pentest reports from my seniors to build a solid checklist. atm security basically has a few layers: physical, network, and software. i’m not gonna cover every single layer here because that would take forever, but i’ll walk you through the core stuff.

we were handed a tool called the “throwing star lan tap pro” for some man-in-the-middle action. and a crowbar, nah, i’m just messing with you, hahaha! the next day, we arrived onsite and started poking at the atm (it was a hyosung, if i recall correctly). here’s a breakdown of the negative and positive findings from the trenches. let’s gooo!

Man In The Middle With Throwing Star LAN Tap Pro

alright bro, first up was the network. i noticed the atm was hooked up to an exposed lan cable right there on the wall, and the cable management was sketchy as hell. quick heads-up: our target was production, so whatever we tested would have a direct impact.

since the lan was just plugged into the wall, i could easily yank it out without any hassle. using the throwing star lan tap pro, we basically became the middleman between the atm and the wall port, letting us analyze the traffic. (fun fact: on some atm pentests, the traffic isn’t even encrypted, so pins, nominals, and other data just pop up in plain text on wireshark).

unfortunately for me, this scenario was a bust. when i fired up wireshark, the only traffic detected was fully encrypted (tls). so yeah, this scenario failed, but you guys can definitely give it a spin if you run into a similar case!

Missing BIOS Password Protection

after the network, i pivoted to the operating system. this beast was running windows 10 iot edition, which at the time was still officially supported directly by microsoft (pretty sure it’s eol by now).

while poking around, a thought crossed my mind: what if we just pop into the bios and kill secure boot to fire up a kali linux live usb? sure enough, i gave it a shot. i opened it up and boom! the bios wasn’t locked or password-protected at all.

i went ahead and disabled some security functions, mainly secure boot, plugged in my kali linux live usb, and the thing booted perfectly. quick side note: i can’t drop any pictures here because company projects are strictly confidential. i immediately hit up my senior like, “mas, have you ever gotten a similar finding?” he just replied, “yep, put it in as a finding.” and just like that, i bagged my first real finding on this atm pentest.

Outdated OS Version

this next one actually served me a massive slice of humble pie and taught me a solid lesson in validation.

while checking out the os, i pulled up “about” and “system information” on this windows 10 iot box. coincidently, i had heard some chatter about windows 10 hitting its end of life (eol). i did a quick google search without actually specifying the exact iot build number. without thinking critically, i was just like, “oh sweet, windows 10 is eol, let’s just make it a finding.”

as a result, the client hit me with the facts: this specific windows 10 iot build actually had about half a year of lifecycle left. from here, we learn to be critical of things and not just blindly validate like i did.

what is the impact of this finding? honestly, the effort to attack is quite high, and sometimes i feel it doesn’t make sense since many attack models require specific conditions to be exploited. but i was terrified that if i didn’t flag this, and one day this windows version actually hits eol and a zero-day or cve drops, i’d be the one taking the heat.

Default Credential — ATM Control Panel

alright, moving up from the os level to the application/software level. since i knew the software name and the atm model, i just searched google to see if it had default credentials.

when opening the control panel, there were several users we could use to log in: supervisor, operator, and technician. my buddy and i dug into the documentation for this specific atm, and sure enough, we found a pdf providing exactly what we needed. we were able to log into all 3 accounts using the default credentials.

the impact here is massive. an attacker could completely alter the atm’s configuration, view logs, reset passwords, and more. basically a cheat code.

ATM Pin Cover Implementation

i actually learned about this specific check from a buddy of mine when i was picking his brain about atm pentests before this gig.

why is this even considered a finding? well, according to him, this applies specifically to scenarios where there are two atms sitting side-by-side in a cramped little room. because of the tight space, the bank has to implement a physical pin cover (keypad shield) on the machine so the person standing next to you can’t just shoulder-surf your pin. if someone catches your pin and, worst-case scenario, you drop your atm card or get skimmed, it’s basically game over.

i double-checked this with my senior at the office, and they were like, “yep, just put it in the report as a finding.” however, in my specific test case, the atm i was testing had already implemented the pin cover properly. so, it went down in the report as a positive finding. but honestly, if you think about it, isn’t a pin cover just basic common sense best practice? hahahahaha.

A Friend’s Finding (Because it’s crazy, I’m including it) ATM Jackpotting

i read this from my senior’s report during a recent atm pentest for this year’s pci-dss audit. since this jackpotting finding is incredibly cool, i’m going to share it too, hopefully it can be a good reference for you guys.

previously, i had tried something similar on my project, but because my windows iot had an edr running, i couldn’t bypass it (especially since i hadn’t learned maldev at the time). but on my buddy’s case? the atm had absolutely zero edr. it was only running standard windows defender.

this jackpotting tool is open source, and you can use several techniques to bypass defender to get the software running. when my senior ran the jackpotting software and inputted a nominal amount, sure enough, the software worked flawlessly, dispensing cash automatically. the impact? we can get rich hahahahaha.

Conclusion

at the end of the day, pentesting an atm is a completely different ballgame and a wild experience. it takes care of showing you how hardware, networks, and software all tie together in the real world.

alright, that is probably enough for this quick write-up! if you guys run into any weird setups, feel like something is missing, or spot any mistakes in this walkthrough, just shoot me an email at iam0xc4t@gmail.com or ping me on socials. thanks for reading, everyone!

./0xc4t.re