第51話で、イトは同じpasswordを二回入れて2FAにしなかった。
knowledge / possessionの別railを通し、accepted TOTPのreplayも止めた。
その直後、lab wallの裏側に同じ形のlogin gateが光る。
urgent mailには、見慣れたlogoと自然な文章がある。
protected settingを保つには再確認が必要です
残り十秒
passwordとcurrent OTPを入力してください
表示senderも知っている名前だ。
link previewはHTTPSに見える。
「見た目が全部そろっているなら、開いてから確かめればいいよね」
イトはmessage内buttonへ指を伸ばした。
countdownは九、八、七と減っていく。
phishingは、偽verifierへevidenceを渡させる
ピコはbuttonへ触れず、messageからfake gateへ伸びるred routeだけを照らした。
イト
変な日本語もないし、logoもsender名も同じだよ
ピコ
本物らしさは、messageが本物だというproofではないよ
イト
URLの一文字違いを見つければ判定できる？
ピコ
clueにはなる。でも、当てることより先にrouteを切り替えられる
この話のmail、account service、fake / official gate、relay traceは、外のInternetから切り離した学習fixtureだ。
実organization、credential、OTP、URL、phone number、live phishing pageは使わない。
添付file解析、email authentication、punycode、browser製品UI、WebAuthn protocol詳細も再現しない。
logoやdisplay senderは、出発点を証明しない
FTCのphishing consumer adviceは、知っているcompanyのlogoを使い、本物らしく見えるmailでもphishingであり得る例を示す。
表示名、logo、丁寧な日本語、過去のconversation風thread。
それぞれは安心させる材料として複製・偽装され得る。
逆に、typoや不自然な文面がないこともgenuineの証明にはならない。
「怪しい文面を見抜けた人だけが安全」という設計にしない。
unexpected requestがcredential、payment、personal information、link clickを求めた時点で、message routeを止めて別channelへ移れるようにする。
urgencyは、serviceのdeadlineとは限らない
mail内countdownは三秒になった。
でも、そのclockを動かしているのはmessage側だ。
official account serviceのdeadlineと同じだというevidenceはない。
CISA Secure Our Worldのphishing guidanceは、urgent / emotionally appealing language、personal / financial information要求、shortened URL等をphishingのcommon signとして扱い、recognize / reportへ進むよう案内する。
signは「必ず偽物」と自動判定するstampではない。
止まり、別routeで確認する理由だ。
countdownへ従うことと、accountを守ることを同一にしない。
URLを見るだけでなく、URLを選び直す
messageには三つのcontact routeが埋め込まれている。
button link。
reply address。
support phone label。
どれもmessage senderが用意した情報だ。
同じmessage内の別routeへ移っても、independent verificationにならない場合がある。
FTCは、requestが本物か確認するなら、mail内情報ではなく、自分がrealだと知るwebsiteやphone numberでcompanyへ連絡するよう勧める。
known official app。
以前から保存したbookmark。
自分で管理しているpassword managerのknown origin。
契約書、card裏面、別に取得したofficial contact。
このfixtureでは、改修前からlab端末へ保存されていたread-only official bookmarkを使う。
search resultの上位や広告を、その場で新しいknown routeに昇格させない。
HTTPSは、意図したorganization名のstampではない
message linkにもHTTPS indicatorがある。
それは、そのexact destinationとの通信にTLSが使われる手掛かりにはなる。
しかし「イトが行きたかったorganizationのhostか」は別の問いだ。
attacker-controlled hostも、そのhost名に対するcertificateを持ち、HTTPSを使える。
鍵markだけからbrand / organizationの正当性を決めない。
この回ではTLS handshakeやcertificate validationへ入らず、known destinationの選択とprotected transportを分ける。
manual-entry OTPもrelayされ得る
fake gateはpasswordだけでなくcurrent OTPも要求する。
「二factorならfake gateで止まる」とは限らない。
NIST SP 800-63B-4のPhishing Resistanceは、manual-entry OTPをspecific sessionへbindしないためphishing-resistantとは扱わない。
impostor verifierがuserから受け取ったauthenticator outputを、real verifierへ短時間にrelayできるからだ。
このfixtureのisolated traceでは、synthetic password / OTP placeholderがfake gateへ入ると、red routeがofficial verifierへそのまま伸びる。
real credentialは流さない。
attack手順やlive endpointも作らない。
見るのは、「OTPがone-timeでも、使われる前にimpostorへ渡せば安心ではない」という境界だけだ。
イトの前に、三つの選択肢が開く
mail countdownは一秒で止まり、screen全体がredに変わった。
A message buttonを開き、pageの中で判断する
移動先を見られる。
でもmessage routeへ入り、入力やdownloadを促すstageまで進む。
B logo、display sender、HTTPSが揃ったのでgenuineと決める
appearance clueは多い。
しかし、どれもrequested organizationのindependent event evidenceではない。
C message routeを閉じ、known official routeからrequestを確認する
messageを削除する前にreceived time、full sender、target metadataをfixture evidence envelopeへ保つ。
link、reply、message内phoneは使わない。
pre-existing official bookmarkからaccount eventへ入り、該当requestの有無を確認する。
ピコはmailを閉じず、official bookmarkも押さなかった。
「偽物を当てる前に、このmailが作った道から降りる」
イトはCを選んだ。
urgent buttonへ伸ばした手を戻し、message routeのlink / reply / phone shuttersを自分で閉じ、pre-existing official bookmark cardをblue independent railへ置いた。
official routeには、urgent requestがなかった
イトはknown official fixtureへ新しいrequestを作った。
account event ledgerを開く。
第51話のprotected settingはaccepted済みだ。
additional reauthentication requestはない。
account suspension eventもない。
mail countdownとofficial event ledgerは対応していなかった。
イトはofficial report controlからmessage envelopeをquarantine trayへ送った。
message button openは0。
credential / OTP transmissionは0。
official urgent eventは0。
quarantined messageは1。
見た目からfakeを言い当てたからではない。
messageが指定したrouteを使わず、known routeでrequestそのものを確かめた結果だ。
もし入力したなら、閉じるだけで終わらせない
何をしたかで初動を分ける。
開いただけで、入力・download・permission grantがない。
passwordを入力した。
OTPを入力した、またはlogin approvalを許可した。
payment / personal informationを渡した。
「閉じたから全部元通り」とは決めない。
known official routeからpassword変更、active session / factor / account activity確認、service supportへの連絡を行う。
仕事用accountならorganizationのincident reporting ruleへ進む。
payment情報なら、message内連絡先ではなくcard issuer / financial institutionのknown official channelで案内を確認する。
端末でdownloadやpermission grantをした場合は、organizationやplatformのsecurity guidanceへescalateする。
この回は一律のrecovery guaranteeを出さず、exposure typeとofficial response ownerを分ける。
phishingを疑ったら、判定より先にrouteを変える
workbenchには四つの結果が残った。
closed message link / reply / phone shutters。
pre-existing official bookmarkから伸びるblue independent rail。
urgent event 0のofficial ledger。
reported / quarantined message envelope。
unexpected messageがcredential、OTP、payment、personal informationを求めたら、まずmessage内link / reply / phoneを使わない。logo、display sender、文面、HTTPSだけでgenuineと決めず、自分が以前から知るofficial app / bookmark / website / separately obtained contactへrouteを切り替え、requestの有無を確認する。入力済みなら閉じるだけで終えず、official channelからexposureに応じたrecovery / reportへ進む。
「見抜いたんじゃない。選ぶ入口を変えたんだ」
イトはred message routeを消去せずevidence trayへ封じ、blue known routeだけをcurrent workbenchへ残した。
official gateの手前には、transparent tunnelとcertificate holderがある。
known URLを選んだあと、その通信路は何を確かめているのだろう。
次回：鍵markは、何を保証する？
イトはofficial hostname cardとserver certificate cardを別holderへ置いた。
「暗号化されていることと、行きたい相手につながることは、どこで結ばれる？」
ピコはTLS tunnelの入口だけを照らした。
次回、ピコルート第53話。
イトは、鍵markだけで本物と決めなかった｜TLSは何を結ぶ？