悪意のある通信は、暗号化されたネットワークトラフィックに適度に隠されていますか？
現在、多くのWebサイトがTLS/httpsを使用してすべてのネットワークトラフィックを暗号化していることを考えると、クライアントマシンが危険にさらされ、追加の指示とデータ抽出のためにC＆Cサーバーへのバックチャネルを確立する必要がある場合、HTTPSで正常に非表示にできますかトラフィック？
ネットワークベースの侵入検知システムは、HTTPSプロキシを利用しない限り、最初のページの読み込み後に他にどのようなリソースが読み込まれるかについてほとんど知識がありません。マルウェアがHTTPSリクエストで疑わしいヘッダーデータを使用してハートビートを送信する場合（そしてステガノグラフィで処理された画像の形でタスクを取り戻す場合、DNSリクエストが何もトリガーせず、IPがトリガーされない場合、通常のネットワークベースのIDSはそれを取得できますブラックリストに載っていませんか？
さらに、ポート443は通常ファイアウォールで許可されているため（そして確立された接続は通常は元に戻されます）、これは一目で隠すのに適した場所のようです。
適切に暗号化されている場合、これが悪意のあるコンテンツであるとどのように判断できますか？これにより、マルウェアはほとんどの分析の観点から通信を隠すことができますか？
この方法で通信を隠すマルウェアを検出して検出するための可能な方法は何ですか？つまり、必要なときに単一のリクエストを送信し、Facebookの初期読み込みなど、さまざまなサーバーに大量のhttpsトラフィックが進行中です。
HTTPSを使用すると、トラフィックペイロードからマルウェアを検出するのがはるかに困難になりますが、通信はプレーンHTTPで隠すこともできます。これは、たとえば、転送されたメッセージを共有シークレットで暗号化するか、ステガノグラフィ技術を使用して行われます。
それでも、コンテンツではなくトラフィックのメタデータを調べることで、検出が可能になる場合があります。このようなメタデータは、たとえばトラフィックパターンです。TLSを使用しても、トラフィックの方向とサイズは引き続き表示されます。つまり、要求が送信されたときと応答が受信されたときに表示されます。通常のブラウザでHTMLページにアクセスすると、HTMLページをロードすると埋め込みリソースがダウンロードされるため、要求と応答のバーストが発生します。その他のメタデータは、クライアントによって提供される暗号とその順序、使用されるTLS拡張、返される証明書の種類など、TLSハンドシェイクの機能です。その他のメタデータは、ターゲットとリクエストのタイミング、 DNSトラフィックなど。
このトピックに関してシスコによる興味深い調査がありました。たとえば、 暗号化されたマルウェアトラフィックの検出（復号化なし） を参照してください。このリンクの最後には、さらなる研究への参照もあります。