Skip to content
KitploitKITPLOIT
ツールブログ
提出
ツールブログ
提出

ハッキング、侵入テスト、サイバーセキュリティツールをあなたのセキュリティアーセナルに!

Kitploitはハッキング、サイバーセキュリティ、ペネトレーションテストのツールディレクトリです。最新のプロジェクトアップデートを見つけて、脆弱性の発見、システム分析、テストの自動化、セキュリティの強化を行いましょう。

··フィード·お問い合わせ·プライバシー·© 2026 Kitploit

ツールディレクトリ

カテゴリ

すべてのカテゴリを見る
Loading categories
log4j — Log4Shell(CVE-2021-44228)に関する厳選OSINT情報集。検出手法、攻撃対象領域、緩和策、およびインシデントレスポンスのための侵害指標(IoC)を網羅しています。 | Kitploit
ツール/GitHubGitHub/dariusiakabos/log4j
脆弱性分析脅威インテリジェンス学習と教育インシデントレスポンス厳選リソース
GitHubdariusiakabos/log4j

log4j

Log4Shell(CVE-2021-44228)に関する厳選OSINT情報集。検出手法、攻撃対象領域、緩和策、およびインシデントレスポンスのための侵害指標(IoC)を網羅しています。

リポジトリを見る
614年前未レビュー

人気

すべて見る →

コミュニティで最も使われているツールを見つけましょう。

すべてのツールを探索

ツールコレクションを閲覧

すべてのツールを見る →
共有

Log4J ゼロデイ

log4j のOSINT調査結果のまとめ。検出、攻撃対象領域、緩和策、IoCを含む。

I. 概要

要約

  • この脆弱性により、ログメッセージやログメッセージのパラメータにテキストを注入できる攻撃者は誰でも、リモートサーバーからコードをロードできるようになります。対象となるサーバーは、Java Naming and Directory Interface(JNDI)への呼び出しを介してそのコードを実行します。

  • JNDIは、いくつかのネットワークサービスとインターフェースします:

    1. Lightweight Directory Access Protocol(LDAP)- デフォルトポート389
    2. Secure LDAP(LDAPS)- デフォルトポート636
    3. Domain Name Service - デフォルトポート53
    4. JavaのRemote Interface(RMI)- デフォルトポート1099
    5. Common Object Request Broker(CORBA)
  • 2021年12月13日時点で、これまでの攻撃は、暗号通貨マイナーと自動化されたボットネット(Mirai、Tsunami、Kinsing)のいずれかでした。

  • 最善の修正方法はパッチ適用済みバージョンへのアップグレードですが、課題はlog4jがコンポーネントとしてどこに配備されているかを見つけること、および/またはベンダーのパッチを待つことです。

  • 短期的な対策:

    • 良い:LDAPおよびRMIの送信ポートをブロックする
    • より良い:LDAPおよびRMIプロトコルを(ポートに関係なく)ブロックする
    • 最善:すべての送信トラフィックをブロックする
  • 長期的な対策:

    • Log4Jのインスタンスを特定して更新するか、Log4Jの設定を変更して問題を緩和する(Log4Jのパス設定のルートにあるXMLまたはYAML設定ファイルを通じて、またはプログラム的に)。Log4Jが組み込まれている製品ではコード変更が必要になる場合があります。

影響を受けるバージョン:

  • Apache Log4j v2.0 -> v2.14.1
  • Apache Strutsフレームワークを使用している人は誰でも脆弱である可能性が高い

主なリソース:

Swiss CERTのLog4Jガイドライン

https://www.govcert.admin.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j/

これを取り上げている主要ブログ:

https://www.lunasec.io/docs/blog/log4j-zero-day/

log4jに関する情報の収集(影響を受ける製品を含む)

https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/ - @TychoTithonus(Royce Williams)著

攻撃対象領域

エクスプロイト例のまとめ。 https://github.com/YfryTchsGD/Log4jAttackSurface

II. 検出

Florian Rothによるリソース(コメント欄にも有用な情報があります) https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b

Florian RothによるLog4Shell Detector V0.5

https://github.com/Neo23x0/log4shell-detector

Elastic(Lucene)用の正規表現クエリ

/.({|%7B)[Jj][Nn][Dd][Ii]./

脆弱なlog4jバージョンのハッシュ

https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes

log4shell脆弱性のテスト用アプリ

a) Canarytokens

自動:

https://twitter.com/ThinkstCanary/status/1469439743905697797 https://canarytokens.org のポイント&クリック型canarytokenを使用して、#log4j / #Log4Shell の問題をテストできます。

  1. https://canarytokens.org にアクセスします;
  2. Log4shellトークンを選択します;
  3. 通知を受け取りたいメールアドレスを入力します;
  4. 返された文字列をコピー/使用します...

手動

  1. DNSトークンを生成します https://canarytokens.org/generate#
  2. そのトークンを次のようにラップします プレフィックス:${jndi:ldap:// サフィックス:/a}
  3. アプリの検索フォーム、プロフィールデータ、設定などでその値を使用します
  4. 反応がトリガーされたら通知を受け取ります

b) Huntress Log4Shell Vulnerability Tester

詳細は彼らのページにあります https://log4shell.huntress.com/

脆弱なコードパスを探すためのJavaソースコード検索用のsemgrepルール

https://github.com/returntocorp/semgrep-rules/pull/1650/commits/ecfc32623eec718d61ec83b9196574f333191008

SnortおよびSuricataの検出

https://twitter.com/ET_Labs/status/1469339963871354884

netcatを使用した代替検出方法

「影響を受けているかどうかを検出する方法:アプリと並行してnetcatを起動します:"nc -lp 1234"、次にアプリのログに記録される場所(例:検索のクエリ文字列)に次のように入力します:"${jndi:ldap://127.0.0.1:1234/abc}" netcatコンソールにガベージ/絵文字が表示されたら、あなたは脆弱です!」

III. 緩和策:

1. 恒久的な緩和策(パッチ適用)

  • log4jバージョンをlog4j-2.15.0-rc1にアップグレードします
  • URL: https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/2.15.0/
  • リリースノート: https://logging.apache.org/log4j/2.x/changes-report.html#a2.15.0
  • アナウンス: https://logging.apache.org/log4j/2.x/security.html

2. 一時的/部分的な緩和策

a) 部分的な緩和策:

  • ユーザーは、アプリケーションを起動するためのJVMコマンドに"‐Dlog4j2.formatMsgNoLookups=True"を追加して、log4j2.formatMsgNoLookupsをtrueに切り替える必要があります
  • コマンドラインでルックアップを無効にすることは、これらのケースの一部では部分的な緩和策です(ベンダーの対応は不要ですが、アプリがその機能を実際に使用している場合はアプリのロギングを壊す可能性があります。もちろん、ローカル管理者がコマンドラインを制御する必要があります)。

b) 部分的な緩和策

「私は、JndiLookup.lookup()をパッチして固定文字列を返し、引数を解析しないようにする、シンプルな(つまりスタンドアロンで依存関係のない)Javaプログラムを作成しました。これにより、JVMプロセスを再起動せずにCVE-2021-44228(つまりLog4jのRCE)を修正できるはずです。」 https://github.com/simonis/Log4jPatch 「これは、実行中のJVMプロセスにJavaエージェントを注入するシンプルなツールのPOCです。このエージェントは、ロードされたすべてのorg.apache.logging.log4j.core.lookup.JndiLookupインスタンスのlookup()メソッドをパッチして、無条件に文字列"Patched JndiLookup::lookup()"を返すようにします。これにより、Javaプロセスを再起動せずにLog4jのCVE-2021-44228リモートコード実行の脆弱性を修正できるはずです。 これは現在、JDK 8と11でのみテストされています!」

IV. IoC

この脆弱性を大規模に悪用しているIP(APIおよびpython/bashスクリプトについてはコメントを参照)

https://gist.github.com/gnremy/c546c7911d5f876f263309d7161a7217

出典:Greynose.io

https://www.greynoise.io/viz/query/?gnql=tags%3A%22Apache%20Log4j%20RCE%20Attempt%22

コミュニティAPI https://docs.greynoise.io/reference/get_v3-community-ip

悪用試行に使用された不正なLDAPサーバー(ThreatFoxへ)

API呼び出し: curl -X POST https://threatfox-api.abuse[.]ch/api/v1/ -d '{ "query": "taginfo", "tag": "log4j" }

URL: https://threatfox.abuse.ch/browse/tag/log4j/

更新されたC2/コールバックドメインを含む新しいリンク:

https://gist.github.com/superducktoes/9b742f7b44c71b4a0d19790228ce85d8

ペイロード

「GreyNoiseがこれまでに検出した以下の生のCVE-2021-44228 Log4J / Logshellペイロードを参照してください。」 https://gist.github.com/nathanqthai/01808c569903f41a52e7e7b575caa890

追加のペイロード https://gist.github.com/yt0ng/8a87f4328c8c6cde327406ef11e68726

さらなる更新:

https://twitter.com/GreyNoiseIO/with_replies

報告された攻撃:

「45[.]155[.]205[.]233がbase64エンコードされた文字列で初期スキャンを行っているのを確認しました。デコードすると、シェルをセットアップするためにcurl wget bashなどを行おうとします。 ステージ2、3、4も最終ペイロードとともに確認されています: 以下のIPを介したnspps/Kingsingマルウェア 44.240.146.137 45.137.155.55 185.154.53.140 185.191.32.198」

45.155.205.233 - 悪用が確認されているロシアのIP。 https://twitter.com/VessOnSecurity/status/1469950517010968582 https://twitter.com/entropyqueen_/status/1469961345848299520

ツールをダウンロード