昨年よりVBAを悪用した攻撃報告が相次いでいます。2月にSANS ISCからも報告されていますし、Dridex Banking Trojan のような攻撃も報告されています。
＃当初はVBAの悪用に対して懐かしさを感じていました。
一時代前の状況との違いのひとつは、攻撃時のソーシャルエンジニアリング的な要素を強化したことが挙げられます。例えば、マクロを有効化しなければ文章本文が閲覧できないようにするなどです。

このVBAを悪用するトレンドは、アンダーグラウンド市場においても確認できます。
現在、複数のサイバー犯罪者向けのサービスプロバイダー（？）が確認されており、ほとんどがマクロに対応しているようです。
＃もっとも、ちゃんと取引が成立するのかは不明ですが。


                   　図　攻撃コード生成サービス例

約３年前頃と記憶していますが、マルウェア開発者コミュニティ間において、VBSによるマルウェア開発の依頼が記載された時期がありました。恐らく、その頃からVBSやVBAといったエンコード可能な言語による悪性コード開発の需要が高まってきたのではないでしょうか。そして、現在は一定の市場が出来てきたのかもしれません。
この辺の状況は悪性コードにも表れており、VBAがダウンロードする関連ファイルなどは非常に酷似しているものが多く確認されています。例えば、下図の場合は一部のパラメータなどが変わっているだけのものです。
＃エンコードはいずれもbase64を利用。
つまり、同一のツールもしくはサービスを利用して作成したものと推測されます。



既に報告された悪性コードだけでも複数種類あり、全てへの対策は中々骨の折れる作業となります。
また、従来よりも攻撃手口は複雑化しているため、単一のセキュリティソフトウェアだけで検出することも難しい状況です。そういった意味では、様々な観点から検知を試みる必要があるといえます。
ちなみに、独自でIOCなどのルールを記述する場合は、次の文字列の組み合わせが使えそうです。

■ダウンロード機能をYaraなどで検出する場合（例）
    strings:
        $a = "VBA"
        $b = "Root Entry"
        $c = "workbook_open" nocase
        $d = "GET"
        $e = "XMLHTTP" nocase
        $f = "WinHttpRequest" nocase
        $g = "adodb.stream" nocase
       
    condition:
        $a and $b and $c and ($d or $e or $f or $g)

＃中途半端な形での記載で恐縮ですが、使いやすい形にしてご活用ください（笑）

なお、私見ですがVBAやVBSの悪用は暫く続くものと推察しています。と言いますのも、いずれも被害報告が減る兆しが見えないことに加え、既知の攻撃ツールの開発が継続されているためです。
いずれも悪性コードの開発において自由度が高く、従来のセキュリティ対策に対して柔軟に対応可能であることが特徴です。そういった意味では、しばらくイタチごっこの状況となるのではないでしょうか。
近い将来、これらの課題も解決する日が来ると思います。それまではIOCをはじめとした脅威情報を活かすためのフレームワークを作ることが先決かもしれません。現在、世界ではこれらの取組み（STIXなど）がはじまっています。国内においてもそろそろ動き出す頃かもしれません。
その際は是非ご協力頂き、脅威情報など共有頂けると幸いです。