Offensive security consultant focused on OT, ICS and IoT. I assess environments in oil and gas, mining, utilities and manufacturing, I've worked with smart building construction companies on building automation, and my own research found a six-bug chain that could give root on any of the roughly 10 million robots in a consumer robot fleet. I also co-organize DEFCON Toronto, where I find the researchers and presenters worth hearing.
The work I'm proudest of is six months of red team engagements for a Canadian independent power producer. Afterwards I combined the results into a series of working sessions with their IT team that ran for months, and the outcome was a resilience-checking playbook mapped to the compliance requirements they have to meet. I also built the red team pipeline for a major Canadian insurer.
At White Tuque I assess OT environments in oil and gas, mining, utilities and manufacturing. I've tested Modbus TCP, DNP3, S7, EtherNet/IP, Profinet, BACnet, KNX, OPC UA and MQTT, and I map what I find to the Purdue model and MITRE ATT&CK for ICS. For a mining company I contributed to deception-based detection: honeypot-style decoys that turn any attacker contact into a high-confidence alert, catching reconnaissance and lateral movement early without touching production. It suits OT networks, where controllers can't run endpoint agents.
At ASEC I worked with smart building construction companies on the security of their building automation and IoT systems, and ran physical red team engagements for fintech clients that needed them. I took that work to SecTor 2025 with a talk on red teaming the smart building.
I've seen both ends of OT maturity: clients with well-segmented networks and engineers who knew their protocols cold, and clients much further behind. The job is the same either way. Test without putting safety or uptime at risk, and explain findings so the people running the plant can act on them.
In OT, a test that disrupts the process is a failed test. Scope around operating windows, agree what's off limits with the people who run the plant, and prefer passive methods wherever active testing could touch the process.
Findings land when they're framed as safety, availability and process risk, mapped to the Purdue model and MITRE ATT&CK for ICS, not just a list of CVSS scores.
The interesting bugs live in firmware and protocols. Open the device, read the firmware, and follow its traffic to the cloud, the way I did with the Deebot fleet.
I soldered onto the robot's UART, dumped the firmware, recovered cloud credentials and mapped the MQTT topic tree. The broker trusted whatever device identity a client claimed, and the robot ran incoming commands as root with no signature check, so any account could push a shell to anyone's robot, across a fleet of roughly 10 million devices. Six-bug chain, six CVEs filed with MITRE, disclosed under the vendor's Safe Harbor, and presented at BSides Toronto 2026. Read the write-up Talk page
My SecTor 2025 talk, "When Hackers Meet Burglars," on attacking buildings where automation, access control and physical security meet.
Open-source (MIT) workspace that runs offensive security work with an AI agent in the loop: per-engagement isolation, scope tokens, a hash-chained audit log and three-tier command gating. github.com/amir-hosseinpour/eidolon
Canadian permanent resident, based in Toronto. I speak English, Persian and Mandarin. Happy to talk whenever works for you.