IBo nefig：JSOCによる2020年の最高のサイバーセキュリティ開示

今年の前半は終わりに近づいており、今年遭遇したJSOCの生活の中で最も興味深い事例を思い出すことにしました。新規顧客の「旧友」サイバー犯罪者とのミーティング、タスクスケジューラの悪意のあるスクリプト、およびバランサー構成曲線の謎-私たちはカットの下で読んで侵入します。





シリーズサウスパークからのショット

私たちは彼の手書きで彼を認識しました

JSOCの存在中、私たちはさまざまなITインフラストラクチャと、ITランドスケープのカバレッジを監視するためのさまざまな顧客の要望に直面してきました。たとえば、顧客がサーバーのみを監視したい場合、監視対象のセグメントの周囲で何が起こっているかを確認する機会を奪うことがよくあります。このアプローチでは、ほとんどのインフラストラクチャがすでに侵害されている場合、攻撃の検出が遅れる可能性があります。また、既存のお客様にそのような状況がない場合、パイロットプロジェクトではこれは一般的な話です。



そのため、パイロットの1つで、顧客は独自のITランドスケープを再構築する過程にあり、SOCが新しいインフラストラクチャとプロセスにどのように適合するかを確認したいと考えていました。制御できないさまざまな状況のため、単一のネットワークソースが接続されていませんでした。kapetsは、さまざまなインシデントの検出をどれだけ制限していたかを示しています。ドメインコントローラー、いくつかのWindowsサーバー、メールサーバー、およびアンチウイルスのみが接続されていました。パイロットは非常に落ち着いて通過し、私たちにとって標準的でした。インフラストラクチャ、TORの使用、禁止されたRATでいくつかのマルウェアが発見されました。しかし、ある晴れた日、私たちのルールの膨大な数が機能し始めました。その中には、侵入者の痕跡を特定するプロセスを自動化する脅威ハンティングカテゴリのルールが含まれていました。責任あるアナリストは、事件が灯油のようなにおいがすることにすぐに気づき、彼が誰を扱っているのかさえ理解しました。



どうした？最初に目にしたのは、DomainAdminsグループに新しいアカウントを追加することでした。しかし、もう1つのルール、つまり、すでに遭遇したアカウントの疑わしい名前が機能しました。私たちの古い知人である攻撃者は、攻撃中に、スクリプトに記述された2つのアカウントを作成します。これらの2つの名前は、ある被害者から別の被害者に「さまよい」ます。小さな変更は、攻撃された組織のアカウントに名前を付けるためのルールによってのみ発生します。事件を調査している間、私たちは彼に何度も会いました。同じ方法であらゆる規模と業界の組織を攻撃し、通常は会社の主要サーバーを暗号化することになります。



残念ながら、最初に侵害されたマシンは接続されたソースの範囲外であったため、スクリプト自体を起動した瞬間を記録できませんでした。アカウントの作成に続いて、特定のリモート管理ツールの使用を許可するローカルファイアウォールのルール変更をキャプチャし、そのツールのエージェントサービスを作成しました。ちなみに、お客様が使用しているアンチウイルスはこのツールを認識しないため、対応するサービスを作成して処理を開始することで制御しています。







一番上のチェリーは、侵害されたホストへの合法的な暗号化ユーティリティの配布でした。彼はそれをすべてのホストにアップロードする時間がありませんでした。攻撃者は、このインシデントが最初にトリガーされてから23分後にインフラストラクチャから「追い出され」ました。



もちろん、クライアントと私は、インシデントの全体像を把握し、攻撃者のエントリポイントを見つけたいと考えていました。私たちの経験に基づいて、ネットワーク機器にログを要求しましたが、残念ながら、ログのレベルでは結論を出すことができませんでした。ただし、管理者からエッジネットワーク機器の構成を受け取った後、次のことがわかりました



。ipnat inside source static tcp "gray address" 22 "white address" 9922

ip nat inside source static tcp "gray address" 3389 "white address" 33899



そこから、おそらく、そのようなNATが構成されたサーバーの1つがエントリーポイントになったと結論付けられました。これらのサーバーのログを分析し、adminアカウントで認証が成功したことを確認し、Mimikatzを起動してから、ドメイン管理者を作成するスクリプトを起動しました。この事件を通じて、顧客はファイアウォールルール、パスワード、セキュリティポリシーの完全な改訂を行い、インフラストラクチャにさらにいくつかの欠陥を特定しました。また、SOCが組織に必要な理由をより体系的に理解しました。

リモートルーターとホームルーター-ハッカーの楽園

明らかに、企業がリモートコントロールに移行する状況では、エンドデバイスでイベントを監視することがはるかに困難になっています。2つの主な理由があります。

1. 多くの従業員が仕事に個人用デバイスを使用しています。
2. VPN , .

経験豊富な攻撃者でさえホームネットワークに興味を持っていることも明らかな事実です。これは、これが企業の境界への理想的な侵入ポイントになっているためです。



顧客の1人は、従業員の90％がリモート作業モードに切り替えており、すべてがドメインラップトップを持っていました。したがって、上記のポイント2を考慮に入れると、もちろん、エンドデバイスを引き続き監視できます。そして、私たちと対戦したのはこの点でした。



自己分離中のユーザーの1人は、ほぼ1日中VPNに接続しませんでした。結局のところ、彼はまだ企業リソースへのアクセスを必要としていました。彼はVPNを使用しました。私たちは彼の作業用マシンからログを取得し、何か奇妙なものを見ました。疑わしいタスクがタスクスケジューラで作成されました。毎週水曜日の17:00に特定のファイルが起動されました。彼らは理解し始めました。







トレースにより、2つのドキュメントファイルが作成されました。1つはタスクを作成し、もう1つはタスク内の実行可能ファイルでした。ユーザーはGoogleドライブからそれらをダウンロードしました。



検索のこの段階では、顧客のセキュリティサービスはすでに接続されており、内部調査を開始しました。ユーザーは、ドキュメントのダウンロード元であるGoogleドライブへのリンクを含む個人メールへの手紙を受け取ったことが判明しました。徐々にユーザーのルーターにたどり着きました。もちろん、そのログイン/パスワードはadmin \ adminでした（そうでない場合と同じように？）。しかし、最も興味深いのは、ルーターのDNSサーバーの設定にありました。ヨーロッパの国の1つのIPアドレスがそこに示されていました。このアドレスをVirusTotalに移動しました。ほとんどのソースが赤く点灯しました。調査の終了後、顧客から調査用に2つのファイルが送信され、タスクによって起動されたファイルがさまざまなディレクトリを「ウォーク」し、そこからデータをダウンロードし始めたことがわかりました。



インシデントの時系列は次のとおりです。攻撃者はユーザーのルーターにアクセスし、その設定を変更して、自分のサーバーをDNSサーバーとして指定しました。しばらくの間、私は自分の「犠牲者」を見て、ユーザーの個人的なメールに手紙を送りました。この段階で、私たちはそれを見つけ、企業のインフラストラクチャに深く入り込むことを妨げました。

彼らも彼らを壊します

アウトソーシングSOCを使用する初期段階では、イベントソースを段階的に接続することを常にお勧めします。これにより、お客様の側でプロセスをデバッグし、責任範囲を明確に定義し、一般にこの形式に慣れることができます。そのため、新しい顧客の1つで、最初にドメインコントローラー、ファイアウォール、プロキシ、さまざまな情報セキュリティツール、メール、DNS、DHCPサーバー、その他いくつかの異なるサーバーなどの基本的なソースを接続しました。また、本社の管理者のマシンをローカルログのレベルで接続することも提案しましたが、これまでのところ不要であり、管理者を信頼しているとのことでした。ここで、実際、私たちの物語が始まります。



ある日、イベントがやってきました。大規模なDDoS攻撃が原因で、データセンターが「落ちた」とのことで、現在は復旧に取り組んでいることをお客様から知りました。これはすぐに多くの疑問を投げかけました-結局のところ、DDoS保護システムは私たちに接続されていました。



アナリストはすぐにログを調べ始めましたが、疑わしいものは何も見つかりませんでした。すべてが通常モードでした。次に、ネットワークログを見ると、着信トラフィックを処理する2つのサーバー間で負荷を分散するバランサーの奇妙な動作に気づきました。ロードバランサーは負荷を分散しませんでしたが、逆に、「チョークアップ」されるまで1つのサーバーのみに負荷を転送し、その後、フローを2番目のノードにリダイレクトしました。しかし、両方のサーバーがダウンするとすぐに、このトラフィックがさらに進み、一般的にすべてを「配置」することは、はるかに興味深いことです。修復作業が行われている間に、顧客は誰が混乱したかを知りました。これで事件は終わりだと思われます。情報のセキュリティとは何の関係もなく、単に曲がった手に関連しているだけです。管理者エラー。しかし、顧客は最後まで調査することにしました。管理者のAWPを確認した後、彼はすべてのOSログが同じ職人になる予定の人から削除されていることを発見し、先週の彼の行動を確認するように依頼しました。



興味深いことに、この管理者は事件の数週間前に私たちの調査の対象でした。彼はローカルネットワークからポート22の外部ホストにアクセスしました。その後、この事件は正当なものとしてマークされました。管理者は、外部リソースを使用して自分の作業を自動化したり、新しい機器設定をテストしたりすることを禁じられていません。おそらく、データセンターの崩壊と外部ホストへの呼び出しとの間のこの接続は気付かれなかったでしょうが、別の事件がありました：テストセグメントのサーバーの1つから、管理者が以前に連絡したインターネット上の同じホストへの呼び出し-この事件は顧客によっても記録されました正当なものとして。管理者のアクティビティを確認したところ、テストセグメントからこのサーバーへの絶え間ない要求があり、顧客にテストを依頼しました。



そして、これがデノウメントです。顧客のメインWebサイトの部分的な機能を実装するWebサーバーがそのサーバーにデプロイされました。管理者は、自分の目的でユーザーデータを収集するために、着信トラフィックの一部を偽のサイトにリダイレクトすることを計画していたことが判明しました。

結果

すでに2020年であるという事実にもかかわらず、多くの組織は依然として情報セキュリティの一般的な真実に固執しておらず、彼ら自身のスタッフの無責任は悲惨な結果につながる可能性があります。



この点で、ここにいくつかのヒントがあります：

1. RDPとSSHを他のポートの背後に隠したとしても、外部に公開しないでください。役に立ちません。
2. 侵入者の検出を高速化するために、可能な限り高いロギングレベルを調整します。
3. Threat Hunting . TTPs , . .
4. , . , , .

, Solar JSOC (artkild)