Trusted Design
Code signing provides a level of authenticity on a binary from the developer and a guarantee that the binary has not been tampered with. (Citation: Wikipedia Code Signing) However, adversaries are known to use code signing certificates to masquerade malware and tools as legitimate binaries (Citation: Janicab). The certificates used during an operation may be created, forged, or stolen by the adversary. (Citation: Securelist Digital Certificates) (Citation: Symantec Digital Certificates)
Code signing to verify software on first run can be used on modern Windows and macOS/OS X systems. It is not used on Linux due to the decentralized nature of the platform. (Citation: Wikipedia Code Signing)
Code signing certificates may be used to bypass security policies that require signed code to execute on a system.
T1116は「Code Signing（コード署名）」として定義されていた、主に「防御回避（Defense Evasion）」戦術に分類される非常に重要なテクニックです。
現在は、アクセストークンや証明書といった暗号資産（クレデンシャル）を悪用する大きな分類である T1553.002「Subvert Trust Controls: Code Signing（信頼制御の覆滅：コード署名）」 にサブテクニックとして整理・統合されています。
WindowsやmacOSなどの現代のOSが持つ「正規の証明書でサイン（署名）されているプログラムは安全である」という信頼チェーンの仕組みを逆手に取り、マルウェアに不正なデジタル署名を施すことで、セキュリティ製品の検知をすり抜けて実行させる手法です。
この手法で攻撃者は、「ウイルス対策ソフトやOSの強力なブロック機能を『正規の安全なソフトウェア』のふりをして完全に無力化し、標的のパソコンでマルウェアを確実に起動させること」を実現します。
セキュリティ製品の検知回避:
多くのアンチウイルスやEDR（Endpoint Detection and Response）は、デジタル署名があるファイルを「安全である可能性が高い」と判断し、スキャンの優先度を下げたり、警告を出さずに実行を許可したりする傾向があります。T1116はこの信頼の隙間を突きます。
OSレベルの実行制限（スマートスクリーン等）の突破:
WindowsのSmartScreenやmacOSのGatekeeperは、インターネットからダウンロードした「未署名の野良アプリ」を強力にブロックします。マルウェアに有効なコード署名を与えれば、OSはこれを「身元の確かなソフト」と誤認するため、ユーザーに怪しい警告画面を見せることなく一発で実行させることができます。
攻撃者がマルウェアにデジタル署名を持たせるアプローチには、主に以下の3つの手口があります。
開発企業への侵入:
攻撃者はまず、正規のソフトウェア開発企業やゲーム会社などのネットワークに侵入します。
証明書の盗み出し:
開発環境やビルドサーバーから、アプリに署名するための「コード署名証明書（PFXファイルなど）」と、それに紐づく秘密鍵を窃取します。
マルウェアへの署名:
自陣に戻り、盗んだ本物の証明書を使ってマルウェアに署名を施します。これにより、世界中のOSやセキュリティソフトから見て「その有名企業が作った本物のソフト」と区別がつかない凶悪なマルウェアが完成します。
ダミー企業の設立:
攻撃者が架空のソフトウェア会社を設立し、正規の認証局（DigiCertやSectigoなど）から合法的にコード署名証明書を購入・取得します。
ルート証明書の強制インストール:
あるいは、ターゲットの端末に一度侵入した後に、攻撃者自身が作成した「オレオレ認証局（自己署名）」のルート証明書を、OSの信頼された証明書ストアに強制的に登録（インジェクション）します。これにより、以降はその偽の認証局で署名したマルウェアがすべてシステム上で「公式」として認められるようになります。
「署名があるから安全」という盲信を捨て、発行元の信頼性やプロセスの挙動を多層的に検証する必要があります。
証明書失効リスト（CRL/OCSP）のリアルタイム検証（最重要）:
OSやエンドポイントセキュリティ製品において、ファイル実行時に証明書の有効性だけでなく、「すでに盗まれて失効（Revoked）手続きが取られていないか」をネットワーク経由で必ずリアルタイム検証する設定を強制します。
信頼できる発行元（パブリッシャー）の限定:
WindowsのWDAC（Windows Defender Application Control）やAppLocker、あるいはmacOSのMDM（モバイルデバイス管理）ポリシーを用いて、実行を許可するソフトウェアの発行元（例: Microsoft、Apple、社内公認ベンダーのみ）をホワイトリスト化し、知名度の低い海外のダミー企業名義の署名ファイルをブロックします。
署名ファイルであっても振る舞い監視（Behavioral Monitoring）を適用:
「有効なコード署名があるプロセス」であっても、そのプログラムが実行中にSysvolを書き換えたり、不審な外部IPへリバースシェルを張ろうとしたりした場合は、EDRで例外なく検知・隔離する厳格なポリシーを運用します。
CWE-347: Improper Verification of Cryptographic Signature（暗号署名の不適切な検証）
OSやセキュリティ製品が、署名の有無や形式的な正しさだけを検証し、その証明書が置かれている文脈（盗難の可能性や発行元の実態）のディープな検証を怠ってしまう問題。
CWE-295: Improper Certificate Validation（不適切な証明書検証）
信頼チェーンを組み立てる際、失効情報のチェック（CRL）をスキップしたり、改ざんされた信頼ストアのルート証明書を鵜呑みにしてしまったりする実装・運用の弱点。
歴史に名を残す大規模なサイバー攻撃やサプライチェーン攻撃において、このT1116（現T1553.002）は決定打として使われています。
Stuxnet（イラン核施設を狙ったサイバー兵器）の事例:
2010年に発見された歴史的マルウェア「Stuxnet」は、Realtek社やJMicron社といった台湾の有名半導体・ハードウェアメーカーから本物のコード署名証明書を事前に盗み出していました。これにより、Windowsのシステム保護機能を一切起動させることなく、核施設の制御システム（産業用PC）のカーネル層へ無音で侵入することに成功しました。
SolarWinds サプライチェーン攻撃（APT29）の事例:
2020年に発覚した歴史的な国家系攻撃において、ロシア政府系とされるハッカー集団は、SolarWinds社の開発インフラ（ビルドシステム）そのものに潜伏しました。彼らはソースコードの一部をマルウェアにすり替えた後、SolarWinds社の公式な署名プロセスをそのまま通過させました。結果として、世界中の政府機関や大企業に対して「本物のSolarWinds社が公式に署名し、暗号化アップデートとして配信した本物のマルウェア」が配られるという、最悪のサプライチェーン汚染が引き起こされました。
インシデント分析において、「未知の不審なファイルが見つかったが、有効なデジタル署名がついているからこれは白（安全）だろう」と即断するのは現代の脅威環境では致命傷になり得ます。
特に、署名の日時（タイムスタンプ）が数日前のものだったり、発行元の企業名が自社の業務と全く関係のない海外の零細企業だったりした場合は、本手法（T1116）による署名の悪用や、証明書発行プロセスの悪用を強く疑う必要があります。
この攻撃手法に関連する CVE は登録されていません。