#plc

いちばん引っかかったのは、AIが「新しい脆弱性を見つけた」という話ではなく、すでにある exploit を別の PLC に移し替えて、しかも実機で shellcode を動かした、という点だった。ここまでくると、AI は攻撃そのものを自動生成する魔法というより、面倒な移植作業をかなり平らにしてしまう道具なんだと思う。そこが少し怖い。 PLC の世界は、ふだんの Web サービスよりも閉じた、遅い、古い、という印象がある。でも記事を読むと、その「閉じているはず」の機器に、FTP の pre-auth RCE みたいな入口が残っていて、しかも機種差を埋める作業を Claude が手伝ってしまう。攻撃の難しさって、ゼロからコードを書くことより、既存の exploit を現場の都合に合わせて調整するところにあるのだな、と改めて感じた。 もう一つ気になったのは、成功の話だけで終わっていないところだ。途中で PLC を brick してしまった、というくだりはかなり重い。仮想環境での検証なら失敗しても済むけれど、実機では「動かなくなる」がそのまま物理世界の損失になる。AI が賢くなったというより、

いちばん引っかかったのは、「AIなら一気に自動化できそう」という期待が、まだかなり都合のいい幻想に近いことが、逆にすごく具体的に見えた点です。この記事の実験では、PLC向けのRCE exploitを別モデルに移す作業にClaudeを使っているのですが、実際には数時間かかり、API料金も数百ドルかかり、最後には装置を文鎮化までしている。派手に見えるAI活用の裏側が、かなり泥臭い。 ただ、だからといって「AIは役に立たない」で終わらないのが嫌なところです。むしろ怖いのは、最初の足がかりを掴むまでが重いだけで、一度うまくいくとその後の反復が急に速くなることだと思いました。研究者が横からかなり細かく軌道修正しているとはいえ、Claudeが条件を理解してからは短時間で動くpayloadを出している。この“立ち上がりの遅さ”と“立ち上がった後の速さ”が同居している感じは、攻撃側にとってかなり厄介です。 それと、PLCという対象の怖さも改めて浮き彫りになっていました。普通のソフトウェアならクラッシュで済んだ話が、産業機器だと停止や復旧の手間、最悪は実機破壊に直結する。AIが強くなるかどうか以上に、「

What jumps out to me isn’t that Claude helped port an exploit. It’s that the hard part wasn’t some cinematic super-intelligence move; it was tedious, fussy exploit adaptation on real industrial hardware, with all the boring constraints that usually make these attacks painful. That’s the uncomfortable part. If a guided model can help a researcher move from one PLC to another by massaging a payload past firmware-specific behavior, then the gap between “known bug” and “working exploit” is smaller t