Sigcheckでファイルのバージョン番号、タイムスタンプ情報、証明書チェーンを含むデジタル署名の詳細を表示する(転載)


tike retweeted: 『攻撃を確認した事例の1つでは、攻撃者は標的組織への侵入経路として、SSL-VPN製品の脆弱性を悪用後、端末を侵害しSigLoaderを設置』 <span class="ssssschl">【緊急レポート】Microsoft社のデジタル署名ファイルを悪用する</span>「SigLoader」による標的型攻撃を確認 | セキュリティ対策のラック lac.co.jp/lacwatch/repor…:

2020年7月ごろから、Microsoft社のデジタル署名(コードサイニング証明書)されたDLLファイルを悪用するマルウェア「SigLoader」が使われた標的型攻撃を複数確認しています。攻撃者によって、正規のデジタル署名されたファイルを攻撃に悪用された場合、セキュリティ対策製品による検知をすり抜け、広範囲にわたる攻撃活動を容易に実行される恐れがあります。

今回は、このMicrosoft社のデジタル署名されたファイルを悪用するSigLoaderの特徴を紹介します。なお、このSigLoaderを利用する攻撃者は、2020年12月1日に、APT10の可能性があることが@Int2e_氏によってTwitter※1で報告されています。

※1 https://twitter.com/Int2e_/status/1333501729359466502

図1は、SigLoaderで悪用されたDLLファイル(wiaky002_CNC1755D.dll)のデジタル署名をWindowsのファイルプロパティまたはSigcheck※2で確認したものです。

※2 Sigcheck - Windows Sysinternals | Microsoft Docs

青線枠で示すように、署名の有効期間が2019年7月27日で失効しているため、エラーメッセージが出力されていますが、赤線枠のように「Signed」と検証されており、署名は正しいものであることがわかります。

デジタル証明書の詳細、証明書の情報
Microsoft社のデジタル署名を持つDLLファイルの署名の有効性確認
図1 Microsoft社のデジタル署名を持つDLLファイルの署名の有効性確認

また、図2に示すように、このDLLファイルは、Windows 10で利用される「pkeyhelper.dll」のファイルメタ情報やPDBファイル情報を持つことが確認できます。

「wiaky002_CNC1755D.dll」のファイルメタ情報
「wiaky002_CNC1755D.dll」のPDBファイル情報
図2 「wiaky002_CNC1755D.dll」のファイルメタ情報およびPDBファイル情報(一部抜粋)

デジタル署名されたファイルの改ざん手法

SigLoaderは、前述の通りMicrosoft社のデジタル署名されたDLLファイルを読み込み、攻撃に悪用します。一般的にデジタル署名が有効である場合は、署名した組織が実在することやデータが改ざんされていないことなどが証明されており、万一、デジタル署名のあるファイルを改ざんした場合、デジタル署名が無効であると検出されます。

しかし、SigLoaderを利用する攻撃者は、デジタル署名されたDLLファイル内に存在する証明書テーブル(Certificate Table)のサイズを拡張し、そのテーブル内のデータを変更することで、デジタル署名に影響を及ぼさずに、DLLファイルを改ざんしています。

Windowsでは、デジタル署名のハッシュ計算にあたって証明書テーブルを対象範囲外としているため、証明書テーブルを改ざんしたとしてもハッシュ値が一致し、デジタル署名が有効であると表示されます。この手法は、2009年にHugo氏のブログで報告※3されており、その後、2016年にはBlack Hat USAでも発表※4されています。

※3 Changing a Signed Executable without Altering Windows Digital Signatures | Aymeric on Software

※4 Certificate Bypass: Hiding and Executing Malware from a Digitally Signed Executable | Deep Instinct

図3は、Microsoft社のデジタル署名された正規の「pkeyhelper.dll」とSigLoaderが悪用するMicrosoft社のデジタル署名された「wiaky002_CNC1755D.dll(pkeyhelper.dll)」を比較したものです。SigLoaderが悪用する改ざんされたDLLファイルには、正規のDLLファイルには存在しない、赤線枠の領域にデータが含まれていることが確認できます。

「pkeyhelper.dll」正規DLLファイル
「pkeyhelper.dll」改ざんされたDLLファイル
図3 「pkeyhelper.dll」の比較(上:正規DLLファイル/下:改ざんされたDLLファイル)

SigLoaderを使用した攻撃手口の概要

SigLoaderは、DLL Side-Loadingを悪用して実行されます。正規の実行ファイルによって読み込まれたSigLoaderは、最初に実行ファイルと同じディレクトリ内にあるMicrosoft社のデジタル署名がされたDLLファイル、または暗号化されたペイロード(DATファイル)を読み込みデータを復号します。その後、復号したペイロードをメモリ領域に展開し実行します。最終的に実行されるペイロードは、2020年11月20日時点で3種類が確認できています。

図4は、SigLoaderの挙動を示したものであり、SigLoaderを2段階で使用するケース(青矢印)と1段階のみのケース(赤矢印)の2パターン存在することを確認しています。

SigLoaderの動作概要図
図4 SigLoaderの動作概要図(一例)

以降では、VMware製品の正規実行ファイル(ResolutionSet.exe)を悪用して、実行されるSigLoader(vmtools.dll)の攻撃手口を詳しくみていきます。

SigLoaderが読み込むファイル

SigLoaderには図5に示すように、Sigという文字列を起点に読み込むファイルや暗号化方法などがファイル内にハードコード※5されており、このハードコードされた内容を利用してペイロードが展開されていきます。

※5 別のSigLoaderでは、Sigという文字列や暗号化方法などが未記載のものも確認しています。このようなSigLoaderでは、暗号化方法が記載された箇所に暗号化キーなどが含まれています。

SigLoaderにハードコードされたファイル名や暗号化方法
図5 SigLoaderにハードコードされたファイル名や暗号化方法(一例)

まずSigLoaderはMicrosoft社のデジタル署名されたDLLファイル「wiaky002_CNC1755D.dll」を読み込み、ファイル内のオーバーレイ領域に含まれるデータを取得します。今回のケースでは、先ほど紹介した図3の赤線枠に示すオフセット0xBA488からデータ末尾(0xF4090)までを読み込み、そのコードをメモリ領域上に展開します。このオフセット値0xBA488は、データ末尾から図6に示すように、0x39C08(0x39C05から値を1増やし8の倍数で割り切れる値)バイト遡った値から算出されています。

読み込むデータのオフセットの計算式
図6 読み込むデータのオフセットの計算式(一部抜粋)

SigLoaderが利用する暗号化方法

読み込まれたオーバーレイ領域に含まれるデータは、XOR+カスタムDES+AESによって暗号化されています。暗号化キーは図7に示すように、SigLoader自体にハードコードされており、AESキーと初期化ベクトル(赤線枠)、カスタムDESで利用するキー(橙線枠)です。また、このSigLoaderには、2段目で利用されるSigLoader(2nd)のAESキーや初期化ベクトル(青線枠)、カスタムDESで利用するキー(緑線枠)もハードコードされています。

SigLoaderにハードコードされている暗号化キー
図7 SigLoaderにハードコードされている暗号化キー(一部抜粋)

SigLoaderはこれらの暗号化キーを使用して、オーバーレイ領域に読み込まれた暗号化データを図8の順で復号※6し、シェルコードをメモリ領域に展開します。復号は、AESでは鍵長256ビット、ブロックチェイニングとしてCBCモードを使用し、カスタムDESでは、鍵長64ビット、ECBモードを使用します。復号後は、Call命令でシェルコードが展開されたメモリ領域を呼び出します。

※6 別のSigLoaderでは暗号化アルゴリズムの適用順序や適用回数が異なる可能性があります。

SigLoaderによるデータ復号
図8 SigLoaderによるデータ復号(一例)

SigLoaderには、XOR、カスタムDES、AESの3種類の暗号化アルゴリズムが実装されています。これらのうち、SigLoaderで実装されているカスタムDESは、使用される定数に異常はないものの、サブ鍵生成アルゴリズムやラウンド関数などが標準のものと異なっており、標準の暗号化ライブラリでは暗号化されたデータを復号することができません。

また、これらのデータをエンコードするための処理が多数みられ、サブ鍵生成アルゴリズムやラウンド関数などは、攻撃者が自ら実装している可能性があります。また、コード内にRSAの実装を見据えた箇所があることから、今後RSAの処理に関しても実装される可能性があります。

シェルコードによる2段目のSigloader(2nd)作成

復号されたシェルコードは、SigLoader(2nd)を作成するために用いられます。図9は、シェルコードを一部デコンパイルしたものです。特徴的な文字列ecipekac(Cakepice)をチェックするコードが含まれていることが確認できます。

シェルコード内の「ecipekac」を確認するコード
図9 シェルコード内の「ecipekac」を確認するコード(一部抜粋)

このシェルコードには、自身のコード内に以下の3つのコードが分割されて含まれており、これらを組み合わせて、次のDLLファイルを読み込む2段目のSigloader(2nd)を作成します。分割されたデータの組み合わせ方法は、シェルコードに含まれる文字列ecipekacを起点に行われます。

また、この文字列以降の16バイトには、PEファイルを作成する際のメモリ領域を確保する際のサイズ0x39000(図10:橙線枠)およびSection Headersおよびプログラムコードのサイズ0x038E18(図10:紫線枠)が指定されています。

  • Section Headersおよびプログラムコード(図10:緑線枠)
  • NT Header(PE Header)(図11:青線枠)
  • MS-DOS Header/Stub(図11:赤線枠)
Section Headersおよびプログラムコード
図10 Section Headersおよびプログラムコード(一部抜粋)
MS-DOS Header/StubおよびPE Header
図11 MS-DOS Header/StubおよびPE Header

これらのデータの組み換えに際して、最初に図11に示すように赤線枠のMZヘッダが含まれるMS-DOS Header/Stub(0xE0バイト)を事前に確保したメモリー領域にコピーし、次に青線枠のPE Header(0x108バイト)、最後にtextセクションなどが含まれるSection Headersおよびプログラムコード(0x038E18)をコピーし、PEファイル(SigLoader)を作成します。その後は、Call命令で2段目のSigLoaderが展開されたメモリ領域を呼び出します。

SigLoader(2nd)が読み込むファイルと暗号化方法

2段目のSigLoader(2nd)は、前述したSigLoader(1st)とほぼ同様な作りです。SigLoader(2nd)は、図12に示すように、正規実行ファイルと同じディレクトリにあるMicrosoft社のデジタル署名されたDLLファイル「c_apo_ipoib6x.dll」のオーバーレイ領域に含まれるデータを読み込み、データを復号します。その後、復号したシェルコードをメモリ領域上に展開し、Call命令で呼び出します。

このDLLファイルは、図13に示すように、Windows 10で利用される「wintrust.dll」を改ざんしたものです。展開されたシェルコードは、SigLoader(1st)によって作成された文字列Cakepiceを含むシェルコードとは異なります。

なお、データの暗号化方法については、SigLoader(1st)と同様のものが利用されており、データの復号順序は、SigLoader(1st)とは逆順のAES+XOR(Key=0x0)+カスタムDES+XOR(Key=0xBC)です。また、AESおよびカスタムDESの暗号化キーについては、図7に示した青線枠と緑線枠のものが利用されています。

SigLoader(2nd)にハードコードされたファイル名や暗号化方法
図12 SigLoader(2nd)にハードコードされたファイル名や暗号化方法(一例)
「wintrust.dll」のファイルメタ情報
「wintrust.dll」のPDBファイル情報
図13 「wintrust.dll」のファイルメタ情報およびPDBファイル情報(一部抜粋)

シェルコードによる最後のペイロード作成

SigLoader(2nd)によって復号されたシェルコードは、最後のペイロードを作成するために用いられます。最後のペイロード(図14:青線枠)は、シェルコード内にRC4で暗号化されて含まれており、図14の赤線枠で示すRC4キーで復号することで最終的なペイロードをメモリ領域に展開します。復号後は、Call命令でペイロードが展開されたメモリ領域を呼び出します。

RC4キーおよび暗号化されたペイロード
図14 RC4キーおよび暗号化されたペイロード(一例)

最終的に実行されるペイロード(DelfsCake)

最終的に実行されるペイロード(DelfsCake)は、DLL形式で、C2サーバからデータやペイロードなどを受信して実行する機能を有します。

DelfsCakeには、図15に示すようにRSA公開鍵(1024bit)がハードコードされており、この鍵を使用して送信するデータを暗号化します。初期通信時に送信する内容は、図16の通りです。ユーザ名やコンピュータ名、プロセスID、OSバージョン、ビルド番号、ソケット名、実行日時、ランダムに生成した文字列などがC2サーバに送られます。

DelfsCakeにハードコードされたRSA公開鍵
図15 DelfsCakeにハードコードされたRSA公開鍵(一例)
送信されるデータの例(暗号化前)
図16 送信されるデータの例(暗号化前)

DelfsCakeには、表1に示すコマンドが実装されています。なお、コマンド「d」に関しては、コマンドの受信時のデータを使用してライブラリのロードと関数アドレスの取得を行い、その関数をCall命令で呼び出します。Call命令の際に引数として受信したデータを指定することから、単純なコマンド実行を行う命令ではないと考えます。

表1 DelfsCakeのコマンド一覧
命令コマンド説明
d詳細不明
fC2通信の終了
lSleep間隔の設定
sシェルコードの実行

また、このDelfsCakeを実際に動作させてみましたが、2020年10月30日に確認した時点では、図17に示すように、C2サーバに接続後、RSTパケットが戻ってきており、C2サーバからデータは取得できていないため、最終的にどのようなマルウェアが実行されるか不明です。

DLLファイルのC2サーバとの通信例
図17 DLLファイルのC2サーバとの通信例

SigLoaderによって展開される最終的なペイロードは、DelfsCakeの他にも2種類確認しています。1つは、ペネトレーションツールであるMetasploit Framework※7 やCobalt Strike※8で作成されたシェルコードです(図18)。シェルコードは、C2サーバと通信を確立した後、Cobalt Strike Beaconなど次のステージのマルウェアをダウンロードし、実行します。このシェルコードには、特徴的な文字列(baidu.com)が複数ハードコードされていることが確認できます。

※7 Metasploit | Penetration Testing Software, Pen Testing Security | Metasploit

※8 Adversary Simulation and Red Team Operations Software - Cobalt Strike

ペネトレーションツールを利用して作成されたシェルコード
図18 ペネトレーションツールを利用して作成されたシェルコード(一部抜粋)

もう1つも、次のステージのマルウェアをダウンロードし、実行することが主な機能と考えられるマルウェア(GreetCake)です。図19に示すようにRC4キーがハードコードされており、この鍵を使用して送信するデータを暗号化します。また、表2のような、いくつかのコマンド機能が実装されています。

GreetCakeは、C2サーバから特定の命令コマンドを受信することによって、C2サーバからデータをダウンロードし、復号後、PEファイルを実行します。図20に示すように、実行する前にPEファイル内に「hello」という文字列が含まれているか確認するというコードが特徴的です。

表2 GreetCakeのコマンド一覧
命令コマンド説明
0x12CC2通信の終了
0x12Dスレッドを作成し、PEファイルの実行
0x12Fデータ送信(詳細不明)
0x130PEファイルの実行
0x131 - 0x134C2通信制御の設定(スリープ時間、タイムアウトなど)
GreetCakeにハードコードされたRS4キー
図19 GreetCakeにハードコードされたRC4キー(一例)
文字列「hello」を検索するコード
図20 文字列「hello」を検索するコード(一部抜粋)

これら2種類のペイロードについても、DelfsCakeと同様にC2サーバからダウンロードされるデータは取得できていないため、最終的にどのようなマルウェアが実行されるかは不明です。

まとめ

今回は、Microsoft社のデジタル署名されたDLLファイルを悪用するSigLoaderについて紹介しました。

SigLoaderは、デジタル署名されたDLLファイルの悪用、ペイロードの多段利用や攻撃者が独自に開発した暗号化方法の利用と高度な技術が組み込まれたローダです。暗号化方法では、RSAのコードが未実装であり、開発途中の可能性が窺えるため、今後も、さらに機能が向上したSigLoaderによる攻撃が続く可能性があります。

加えて、今回のデジタル署名されたファイルの改ざん手法を悪用した攻撃は、実際のサイバー攻撃の事例としてあまり報告されておらず、既存のセキュリティー対策製品で検出できない可能性があり、注意が必要です。

私たちがSigLoaderの攻撃を確認した事例の1つでは、攻撃者は標的組織への侵入経路として、SSL-VPN製品の脆弱性を悪用後、端末を侵害しSigLoaderを設置していました。SSL-VPN製品を悪用する攻撃は、標的型攻撃に限らず、金銭目的である攻撃者なども悪用しており、これらの製品の脆弱性を悪用されないためにも、日々の脆弱性情報の管理と修正パッチの適用や緩和策の適用などの早急な対応が求められます。

また、2020年10月ごろからZerologonの脆弱性※9が標的型攻撃で悪用されていることが、CISA※10やSymantec社※11から報告されていますので、この脆弱性についても十分に注意する必要があります。

※9 CVE-2020-1472 - セキュリティ更新プログラム ガイド - Microsoft - Netlogon の特権の昇格の脆弱性

※10 APT Actors Chaining Vulnerabilities Against SLTT, Critical Infrastructure, and Elections Organizations | CISA

※11 Japan-Linked Organizations Targeted in Long-Running and Sophisticated Attack Campaign | Symantec Blogs

バックアップ(Sigcheck v2.80)

【転載】「Google ドライブ」を悪用したフィッシング詐欺が急増中、メールの監視をすり抜ける新たな手口の中身


「Google ドライブ」を悪用したフィッシング詐欺が急増中、メールの監視をすり抜ける新たな手口の中身:


【ニュース】

◆「Google ドライブ」を悪用したフィッシング詐欺が急増中、メールの監視をすり抜ける新たな手口の中身 (WIRED, 2020/11/04 08:00)

「Google ドライブ」を悪用したフィッシング詐欺が急増している。迷惑メールのフィルターをすり抜けて不正なリンクをユーザーに届けてしまう今回の新たな詐欺は、いったいどんな手口なのか。
特定のファイルをほかのユーザーと共有するよう設定すると、そのユーザーに通知が送られるようになっている

https://wired.jp/2020/11/04/beware-a-new-google-drive-scam-landing-in-inboxes/

ーー

 ネットの犯罪者たちは、新たな“釣り餌”を見つけたようだ。「Google ドライブ」を悪用したフィッシング詐欺が報告されており、特に問題はなさそうに見える電子メールやポップアップ通知を開くと、不正なウェブサイトに誘導されてしまう。


危険なリンクをクリックさせようとする詐欺行為はインターネットの創世記から存在するが、うっかり罠にはまってしまう人もいるだろう。今回のフィッシング詐欺で特徴的なのは、電子メールや通知はグーグルのシステムから送られてくるという点である。


スマートフォンの場合、ファイル共有を知らせる通知をクリックすると、悪意のあるリンクを含んだドキュメントが表示される。電子メールも同じで、ハッカーが作成した不正なリンクを含むメールがグーグルから送られてくるのだ。


悪用されたファイルの共有設定

Gmailのフィルター機能は非常に優れており、普通の迷惑メールならうまくブロックしてくれる。ところが、このメールはきちんと受信箱に入っているだけでなく、送信元がグーグルであることで詐欺メールには見えない。電子メールのフィルター機能が改良されたことで、犯罪者たちはどうすれば標的に不正なリンクをクリックさせられるか模索しており、今回はGoogle ドライブが選ばれたというわけだ。


Google ドライブの初期設定では、特定のファイルをほかのユーザーと共有するよう設定すると、そのユーザーに通知が送られるようになっている。仕事でプレゼン資料や新プロジェクトの概要を確認してもらいたい場合には便利な機能だが、一方で狙った相手に不正なリンクを見せる格好の手段にもなりうる。


犯罪者たちは膨大な量のGmailアカウントのリストを利用したようで、ここ数週間でかなりの数の被害が報告されている。『WIRED』UK版でもこのフィッシング通知を受け取ったことがあり、そのうち1件にはロシア系の名前のGmailアカウントによって作成されたGoogle スライドのファイルへのリンクが含まれていた。


ファイルの編集履歴を確認したところ、別のファイルのコピーとして作成され編集が繰り返されており、犯罪者たちが犠牲者を増やすために頻繁に新しいユーザーを追加していたことがわかる。『WIRED』UK版はこのメールアドレスの主と連絡をとろうとしたが、返事は来ていない。また問題のファイルは、グーグルの利用規約違反で削除されている。


監視をすり抜けた新たな手法

不正な電子メールや通知には、ロシア語もしくはつたない英語で特定のファイルを共有したいと書かれている。ファイル名はでたらめで、なかには悪意のあるリンクが含まれている。試しにリンクをクリックすると、10月26日に作成されたとみられるウェブサイトが開き、特別なオファーや賞品が当たるくじを宣伝するポップアップが大量に表示された。また、何らかの支払いを受け取るために銀行口座の詳細を確認するよう求めるサイトに飛ぶこともある。


洗練された手口ではないが、電子メールの受信箱やスマートフォンに不正なリンクを届けるには効果的なやり方だ。フリーランスのサイバーセキュリティ専門家で、Twitterで@JCyberSec_のアカウントをもつジェイクは、「リンクを送り付けるのはそう簡単ではありません」と語る。


ジェイクは長年にわたりフィッシング詐欺の調査を続けており、今回のGoogle ドライブ詐欺のメールも受け取ったという。だが、「電子メールはシステム側で厳しく監視されており、大量の迷惑メールが受信箱に届く前の段階で検出されます」と指摘する。ただ、攻撃者は常に新しい方法を試しており、今回はそうはならなかった。


また、フィッシング詐欺はスマートフォンで特に威力を発揮する。ジェイクは「セキュリティ面の管理権限が小さいので、モバイル機器を標的にしたフィッシング攻撃は増えています」と説明する。


完全なブロック方法は存在しない

グーグルの広報担当者は、Google ドライブでの不正を検出するために新たな対策をとったとする一方で、すべてを完全にブロックできる方法は存在しないと説明している。また、セキュリティの回避を困難にするよう方策を講じており、今回のフィッシング詐欺の標的になったユーザーはサポートページから連絡するよう呼びかけている。


ただ、サイバーセキュリティ会社カスペルスキー・ラボのデヴィッド・エムは、「電子メールや通知がグーグルのアカウントからのものである場合、対策を施すのは難しいでしょう。そして、グーグルのアカウントは誰でも簡単につくれます」と話す。


エムはGoogle ドライブ詐欺について、ほかのフィッシング詐欺と同様に、リンクをクリックする前に注意することが重要だと指摘する。「出どころの不明なリンクはクリックしないでください。リンクが送られてくる予定がなく、また送信者を知らないのであれば、反応してはいけません」


なお、昨年は「Google カレンダー」の通知機能に絡んだフィッシング攻撃が増えたことがあったが、今回の手法はこれに似ている。ここではカレンダーの招待を自動で追加する機能が初期設定でオンになっていることが悪用され、危険なリンクを含む通知が送られてきた。通知の送信元は、やはりグーグルのシステムだった。


グーグルのコミュニティフォーラムやSNSへの投稿を見ていると、複数の不正な通知を受け取っているユーザーもいるようで、ここ数週間でGoogle ドライブ関連のフィッシングが急増していることがわかる。一方で、不正なリンクを含むファイルの多くは利用規約違反で削除されている。

.tsファイルの攻略法【InviDownloader】【Xmedia Recode】【動画ゲッター】


 以前vimeo攻略の記事を書いたが、別サイトの攻略が必要となり、メモがてら残しておく。

今回はm3u8(動画プレイリストファイル)とそれに含まれる.tsファイルをダウンロードし、MP4など使いやすい動画ファイルに変換する方法となる。

途中まではコチラのサイトを拝借させていただいている。

そもそもm3u8とは何? 

簡単に説明すると、そもそもm3u8とはプレイリストファイルのことで、中身はテキストファイルと同様で動画のリンク先URLを、このm3u8の中に書き込んでいます。
よって動画ファイルではなく、動画のリンク先を書き込んでいるファイルのことです。
また、動画ファイルはtsファイルとなり、そのファイルパスを書き込んでいます。
(tsファイル自体は動画ファイルです)

イメージ的にm3u8の中身は

https://www.xxxxxx.com/aaa01.ts
https://www.xxxxxx.com/aaa02.ts
https://www.xxxxxx.com/aaa03.ts
https://www.xxxxxx.com/aaa04.ts
https://www.xxxxxx.com/aaa05.ts

この5本のtsファイルを連結し、一つの動画として再生しています。
よって長い動画ファイルも連結することにより再生することができ、またWEBサーバーなどに負荷をかけることがなく便利な形式のようです。

このようにm3u8自体は動画ファイルではありませんので、m3u8単体をダウンロードしても通常の動画ファイルのように再生することができません。

m3u8(.ts)をダウンロード 

m3u8のダウンロードについて、目的が動画のダウンロードの場合はm3u8に記載されているtsファイルをダウンロードしないと意味がありません。
ダウンロードツールを色々と試しましたが、対応できるツールは動画ゲッターでした。
動画ゲッターはこのm3u8に記載されているtsもダウンロードできるよう日々更新されている素晴らしいダウンロードツールです。

動画ゲッターでのダウンロード方法を解説。
ダウンロードしたい動画の再生画面を表示し動画ゲッターを押すと動画を解析し、m3u8ファイルをダウンロードできます。(はじめはこのm3u8をダウンロードします)
m3u8変換 shot2

m3u8ファイルをダウンロードすると自動で解析し、続いてtsファイルを同じ画面からダウンロード可能となります。

この際、ブラウザの設定でダウンロード先は事前に指定しておくようにします。(都度指定する1ファイルずつ保存場所を聞かれます。数ファイルなら問題ないですが、数千ファイルだと地獄を見ます。)
m3u8変換 shot3

tsファイルを結合 

.tsファイルの結合を色々調べるとffmpegなど色々あります。ffmpegの場合はコマンド入力にて動画を連結するようなので、入力する手間がかかります。それに入力間違いもあるかもしれません。

そこで、InviDownloaderのファイル結合機能を使って対応します。

使い方は下記参照


tsファイルからMP4など他の動画ファイルに変換 

連結されたtsファイルは動画ファイルとして再生は可能ですが、対応する再生プレイヤーが限定されるので、場合によってはMP4など使いやすい形式に変換する必要があります。

動画変換ソフトは色々ありますが、ここではシンプルで使いやすい、Xmedia Recodeを使って説明します。

Xmedia Recodeを立ち上げ、ファイルを開くより連結したtsファイルを選択します。
m3u8変換 shot16

変換したい動画形式を選択します。例えばMP4など。
m3u8変換 shot17

リストに追加を押し、エンコードを開始します。
m3u8変換 shot18

エンコード作業中、終わるとエンコードが完了します。
m3u8変換 shot19


【InviDownloaderの入手先】
https://sourceforge.net/projects/invidownloader/

【InviDownloader(1.0.0.4)バックアップ】
https://www.dropbox.com/sh/ibhpq4g3mpl8fzj/AAAck4sw_WRml2YAXhvvKPPaa?dl=0

【Xmedia Recodeの入手先】
https://www.xmedia-recode.de/en/index.php

【Xmedia Recode(3.5.2.0)バックアップ】
https://www.dropbox.com/sh/54obvw3if9ux7wp/AABoOr_aPTLFIkr7NYmKRoc4a?dl=0

【動画ゲッターの入手先】
https://www.douga-getter.com/

ノートパソコン新規購入


今使っているノートパソコンが5年目を迎え、新規購入しようかどうかをずっと悩んでいた。

悩んでいた理由は多少ガタが来ているものの、クリティカルな問題は発生していないからである。

ちなみに今使っているノートパソコンはメモリ8GB、ディスク128GB(SSD)のVAIO Pro 13(VJP131*シリーズ)である。

確かVAIOがソニーから独立して最初にリリースされたモデルである。

購入当時は結構な高スペックであったため、5年経った今でもふつーのスペックのパソコンとしてまだまだ使えるのである。

ガタが来ているのはマウスパッドで、左クリックがほとんど認識されなくなったため、有線マウスで使っている。

データもほとんどオンラインストレージに入れているし、壊れてから買いなおせばよいと思ったのだが、ここにきてハードディスク容量の不足が問題になってきた。

最終的にはオンラインストレージにファイルは保管されるのだが、中間ファイルの生成やオンラインストレージ移行までの一時的な保管でPCのハードディスク容量が必要なのである。

というわけで、後継のノートパソコンの調達を試みることにした。

ちなみに個人的にはノートパソコン購入時の第1候補はVAIOである。

今や日本のパソコンメーカーはほとんど駆逐されてしまい、日本のパソコンメーカーを応援したいというのが大きい。

この時点でのディスプレイサイズベースでのVAIOの製品ラインナップは12型、14型、15型の3種類。

現在使っているのが13.3型なので、12型にしようと思ったのだが、いろいろ見てみると、現在使っているモデルと、販売中の14型が筐体的にはほぼ同じサイズであることが判明し、14型(VAIO SX14 / VJS1438)を選択。


VAIOはスペックを選べることができるので、メモリを16GB、HDDは256GBのSSDを選択した。

重要な保証期間についてはデフォルトで3年がついているが、長く使う予定なので、オプションの4年サポートを付けた。

ちょうどブラックフライデーセールということで、21型の外付けディスプレイとキャリングケースも実質無料でもらえることができた。

新PCの到着が楽しみである。



【転載】JR東日本が「JRE MALLふるさと納税」を開始。概要とキャンペーンを解説



JR東日本が「JRE MALLふるさと納税」を開始。概要とキャンペーンを解説

東日本旅客鉄道=JR東日本は、傘下の株式会社JR東日本ネットステーションと共同で「JRE MALLふるさと納税」のサービスを、2020年10月27日から開設しました。

なお、今回の開設を記念し、2020年10月27日(火)~12月31日(木)の期間で「JRE POINT2,000ポイントプレゼントキャンペーン」を行うとのことです。

JRE MALLふるさと納税の概要

出典:JRE POINTが「貯まる」「使える」JRE MALLふるさと納税

ふるさと納税に進出するオンラインショッピングは増えています。JR東日本も例にもれなかったわけですが、JR東日本ならではの特徴が出たサービスになっているので、確認していきましょう。

ビューカード利用で最大3.5%還元

前提として「JRE MALLふるさと納税」を利用すると、寄付金額100円ごとに1ポイントのJRE POINTが貯まります。しかも、JR東日本の公式クレジットカードである「ビューカード」を使うと、最大3.5%のJRE POINTが貯まるので、持っていればぜひ使いましょう。

なお、JRE MALLに会員登録をし、JRE POINTの連携を行わなくてはいけません。

JRE POINTで寄付も可能

1ポイント=1円として、寄附金の支払いにも利用できます。もちろん、端数の支払いだけをJRE POINTで済ませて、残額をクレジットカードで支払うのも可能です。

なお、JRE POINTを利用して寄附した場合でも、寄付金額100円ごとに1ポイント(JRE POINT)が付与されます。

キャンペーンについて

出典:JRE POINT について | JRE POINTが「貯まる」「使える」JRE MALL

今回のサービス開始を記念し、「JRE POINT 2,000ポイントプレゼントキャンペーン」が開催されます。期間中、合計30,000円以上寄付をした人の中から、抽選で10,000名にJRE POINT2,000ポイントがプレゼントされるとのことです。

なお、2020年10月27日(火)~11月30日(月)にJRE MALLに会員登録の上、JRE POINTを連携すると200ポイントが全員にプレゼントされます。もちろん、キャンペーンへの応募も重複して可能です。そのほか詳細は、「JRE MALL」のホームページを確認しましょう。

パスワード付きzip、内閣府と内閣官房で26日から廃止へ 外部ストレージサービス活用 平井デジタル相(転載)~政府もPPAP撲滅へ!~



パスワード付きzip、内閣府と内閣官房で26日から廃止へ 外部ストレージサービス活用 平井デジタル相 - ITmedia NEWS:

  平井卓也デジタル改革担当相は11月24日の会見で、メールでパスワード付きファイルを送り、パスワードを別送する方法(いわゆるPPAP)について、26日から内閣府、内閣官房で廃止すると発表した。今後、外部へのファイル送信には外部ストレージサービスを活用し、他省庁の状況についても実態調査を進める。

 内閣府の担当者によると、26日までに全職員に外部へのファイル送信時の運用変更について通知する方針だという。今後は主に内閣府が利用する民間のストレージサービスでファイルを共有し、パスワードをメールで送信する。担当者は一例として「Dropbox」などの名前を挙げたが、具体的なサービス名については「セキュリティ対策のため、公表していない」としている。

 また、プロジェクトごとにあらかじめパスワードを決めておくことや、例外的な運用として内閣府の外部サービスにアクセスできない事業者向けに電話や別メールでパスワードを通知することも検討しているという。

 内閣府では中央省庁間でのファイル送信には政府内専用のネットワーク「政府共通ネットワーク」を活用していることからファイルにパスワードをかけていなかったが、外部へファイルを送信する際は、メール内容を中継サーバなどを通じて盗み見されないよう2011年ごろからPPAPを採用。職員が外部向けのメールにファイルを添付して送信すると、ファイルのzipファイル化から別メールでのパスワード送信までを自動で行うシステムを導入していた。

 平井氏は会見で、PPAPについて「セキュリティ対策や受け取り側の利便性の観点から適切ではない」として、現在の方法を廃止する意義を改めて説明。

 さらに「このような取り組みは政府内だけでなく、民間にも影響のある問題」と指摘し、「民間企業の対応も注視しつつ、今後どのようなセキュリティ向上策をとっていくのが望ましいか、民間の知恵をアイデアボックスに送って頂きたい」と政府の意見募集サイト「デジタル改革アイデアボックス」への投稿を呼び掛けた。

 平井氏は17日の会見で、霞が関でPPAPを廃止すると発表。以降、ネット上でも廃止後の運用に注目が集まっていた。

警察庁内端末不正アクセスと5万件の脆弱なVPNホストの公開についてまとめてみた(転載)


警察庁は2020年11月27日、庁内の端末が1年以上前から不正アクセスを受けていたことを発表しました。また同時期に公開された脆弱なVPN機器リストについても併せてここでまとめます。

VPNのパスワードが漏れた可能性

  • 不正アクセスが確認されたのは警察庁情報通信局のノートPC1台。業務物品の手配を行う専用端末として利用されていたもの。
  • ノートPCは他のシステムとは接続されておらず、警察庁は情報流出の可能性は低いと判断。不正アクセスが行われたタイミングでは端末に情報保管を行っていなかった。
  • 複数のIPアドレスから2019年8月から2020年11月中旬まで合計46回の不正アクセスが行われていた。*1
  • ノートPCからインターネット接続を行う際にVPN機器を利用。このVPNのパスワードが第三者に利用された可能性がある。*2
警視庁からの情報提供を受け発覚
  • 2020年11月25日に警視庁から「不正アクセスを受けているのではないか」といった情報提供を受け発覚。
  • 警察庁は警視庁に被害を申告した。*3

同時期に脆弱なVPNホスト5万件が流通

  • 警察庁の不正アクセス被害の原因となったVPN機器が具体的に何かといった情報は発表、報道されていないが、同時期にFortinet社製機器の脆弱性を影響を受けるリストが公開されていた。
  • 2020年11月19日にハッキングフォーラム上に投稿されたもの*4で、CVE-2018-13379の影響を受けるリストとして49,577件の攻撃コードが含まれたURLが列挙されていた。
  • その後同フォーラム上ではコピーしたとみられるファイルや不正アクセスを行い実際にシステムファイルを取得したとされるアーカイブも流通している。このアーカイブにはVPN機器で利用するパスワードが含まれている可能性がある。アーカイブには49,562個のセッションデータとみられるファイルが含まれていたことから、リストに列挙された大半の機器に脆弱性が残っている(残っていた)可能性がある。*5
  • リスト公開の動きを受け、JPCERT/CCも2020年11月27日にパスワード変更対応などの呼びかけを行っている。脆弱性情報の公開から1年以上が経過しており、対象バージョン(かつSSL VPN機能が有効)に該当する場合、侵害事実の確認を含めた調査を行うことが推奨される。
f:id:piyokango:20201129070732p:plain約5万件のリストが流通
CVE-2018-13379って何?
  • CVE-2018-13379はFortinet社FortiOSのSSL VPN機能の脆弱性で、2019年夏に注目された複数のVPN機器の脆弱性の1つ。
  • 脆弱性は今回新たに判明したものではなく、2018年12月にDEVCORE Security Research TeamのMeh Chang氏、Orange Tsai氏により発見されたもの。Forinet社への報告後に脆弱性への対応が行われ、2019年5月24日に修正バージョンが公開されている。その後、2019年8月の研究調査発表で脆弱性の実証コードを含む詳細情報が公開された。
  • パス・トラバーサルの脆弱性で、機器の任意のファイルを認証無しに取得できる。この脆弱性を使い機器上に保管されたセッションデータファイルを取得し、機器の仕様でこのファイルに平文のパスワード文字列が含まれているため、盗んだ情報を使いVPNアカウントが侵害される恐れがある。

発見者による脆弱性デモ動画


リストには警察庁のIPアドレスも存在
  • このリストには国内に設置されたとみられる機器が多数含まれていた。piyokangoはリスト全体の1割(約5400件)が国内のIPアドレスであることを確認している。*6。この内、確認できた組織名は600件以上で、大学などの教育関連や航空関連、独法などの組織名も含まれていた。

辻さんの統計ツイート

Fortinet製SSL-VPNの脆弱性(CVE-2018-13379)を利用した攻撃結果のリストがリークされていますが、そのリストに掲載されているIPアドレスから国を判別してグラフにしてみたところJPは全体の11%ほどでした。 pic.twitter.com/sKC3qxIDH1

— 辻 伸弘 (nobuhiro tsuji) (@ntsuji) 2020年11月28日
f:id:piyokango:20201130061546p:plainリストに含まれていた警察庁のIPアドレス

更新履歴

  • 2020年11月30日 AM 新規作成

*1:警察庁の端末に不正アクセス 1年超で46回、気づかず,日本経済新聞,2020年11月27日

*2:警察庁の端末1台に外部から不正アクセス46回 情報流出は確認されず,毎日新聞,2020年11月27日

*3:警察庁端末に不正アクセス 計46回、1年超気付かず―今月発覚、情報流出なし,時事通信,2020年11月27日

*4:最初の投稿は既に削除されている。投稿者のアバターやHNも変更されている。

*5:行為が行われた時期は不明

*6:アメリカに次いで2番目に多い

【転載】マリオットの罰金は1人当たり7円


 

マリオットの罰金は1人当たり7円

2018年のマリオットのデータ流出事件の罰金は1,840万ポンド(約25億円)で決着する様です。3億3900万人の個人情報データの漏えい事件でしたので、1人当たりに換算すると0.05ポンド(約7円)となります。

www.theregister.com

この攻撃は当初、チェーンのゲスト予約データベースに5億件のレコードを公開したと考えられていましたが、その後の調査により、その数値が下方修正されました。

公開されたデータには、暗号化せずに保存された525万人のゲストのパスポート番号、1850万の暗号化されたパスポート番号、910万の暗号化されたクレジットカード番号が含まれていました。

公共の傷害に侮辱を加え、ICOはマリオットの罰金を当初の信号値である9,900万ポンドから5分の4に削減し、その後、繰り返しかかとを引きずりました。

情報コミッショナーのエリザベス・デナム氏は、「企業が顧客のデータの管理に失敗した場合、その影響は罰金の可能性があるだけでなく、最も重要なのは、データを保護する義務がある一般市民です」と述べています。

(The Register記事より引用)※機械翻訳

 

キタきつねの所感

マリオットは不正行為に対する2019年7月の巨額の罰金提示(9,900万ポンド)を拒否していましたが、規制当局側が、マリオットのインシデント対応(調査への協力)と、COVID-19のビジネスの経済的影響を考慮して、当初の罰金額を1/5に減額した形となりました。

 

GDPRは2018年5月発効で、この事件は2014年から侵害が開始されて2018年9月まで検出されなかった事件だったので、GDPRの巨額なペナルティの対象なのかという観点でも当時議論がありました。

※2018年5月からのGDPR違反部分を対象とした罰金という形になっている様です。

最終的な罰金額1,840万ポンド(約25億円)は、巨額な罰金額ではありますが、コロナの影響を受けて規制当局が割引したという部分には、少し違和感がありました。(それで企業の業績が傾いたら元も子も無いと考えたのだとは思いますが)

 

GDPRの怖い罰金判例はさて置き、Registerの記事には、私自身が知らなかった事件の詳細が書かれていました。これは、10/30に出されたICO(※英国の規制当局)の通知書から引用したものの様です。

 スターウッドは2016年にマリオットに買収されましたが、買収したチェーンのシステムは、買収後にマリオットが閉鎖されるまで、マリオット自身のIT資産から分離されたままでした。

身元不明の悪意のある人々が、2014年7月にスターウッドホテルのネットワーク内のマシンにWebシェルを忍び込みました。その後、そのシェルを使用して、スターウッドのシステムとパスワードを大量に消費するオープンソースツールMimikatzにさまざまなリモートアクセストロイの木馬(RAT)を植え付けました。攻撃者は、より多くのネットワークアカウントを侵害していました。

これらのアカウントには、多要素認証のないアカウントと、主要なデータベースの管理者資格を持つアカウントが含まれていました。それでも、攻撃者の行動は見過ごされていました。

(The Register記事より引用)※機械翻訳

 

今までこうした詳細経緯は表に出てきてなかったかと思います。この通知書、91ページにも及ぶのですが、色々細かく(一部詳細は黒塗りで)書いてます。

 

引用(機械翻訳)しようと思ったのですが、PDFが画像化(文字をコピーできない)されて構成されているので、パッと読んで大事そうな所だけ拾ってみます。

※PCI関係の方は読んでみると色々面白い事が書かれていて勉強になります。

※(普通の方は)上のRegisterの記事を見れば概要理解としては十分かと思います。

 

攻撃の経緯の所ですが、侵入の部分は上の記事にも書かれていますが、Webシェル→RATだった様です。記事には、最終的にどうやってマリオット側が事件に「気づいたかの所までが順を追って書かれています。

 

2015年4月以降、何度かハッカーの攻撃の痕跡があるのですが、6回目の攻撃で(2018年9月)でようやく検知できています。

f:id:foxcafelate:20201031163731p:plain

なかなか検知出来なかった理由の1つが、正規の認証情報(管理者含む)が窃取されて攻撃されている点と、テーブルの全データコピーが監視ソフト(Guardium)のアラート対象外だった事、そしてメモリスクラッピングマルウェア(2017/1)を仕掛けられた事を検知出来ていなかった事にありそうですが、最後にソフトが検知できたのは、テーブルが何行あるかをハッカーが調べようと数えた際に、保護対象であるカード情報が含まれていたので(ギリギリ)検知できたようです。

 

f:id:foxcafelate:20201031163936p:plain

マリオットのITチームと契約してスターウッドのゲスト予約システムを管理していたAccentureは、2018/9/8ソフトの前日のアラートを見て調査に入りますが、マリオットがスターウッドを買収してから初めての(Guardiumの)アラートだった様です。

しかし、皮肉な事に、最後の成果物であるデータファイルは、2018/9/10と調査に入って2日後に外部にエキスポートされてしまいます。ここで再度Guardiumがアラートを出し、”事故”である事をマリオットが認識する事になります。

買収したスターウッドのシステムが元々侵害を受けていた事に起因する事件なのですが、買収時のセキュリティチェック(自社セキュリティ体制への切替)が甘かったという事が、あったのかと思います。

 

更に皮肉な事に、、、ゲスト予約システムを管理していたAccentureの従業員アカウントもこのデータ侵害事件で悪用されていた事が判明します。

 

事件を引き起こした原因(脆弱点)についても、この通知書では書かれています。

PCI DSS(カード情報漏えい側)視点では、PCI DSSの監査(QSA監査)を通っていたとは言え、この分析では、多要素認証がカードデータ環境(CDE)に対する全てのアカウントとシステムアクセスで実施されていなかった事が指摘されています。

この点についてマリオットは、QSAが問題無いと判断した事を持って抗弁した様ですが、最終的に多要素認証の穴(ミス)があったと判断された様です。

 

f:id:foxcafelate:20201031162307p:plain

 

フォレンジック(事故)調査は、Verizonが実施した様で、この辺りでは、ログ監視についての不備が書かれています。読んでいくと、マリオット側は自社で実施してる年次の侵入テスト結果を持っていたのですが、ログ(監視)設定について適切であるかどうかは、こうした脆弱性テストではチェックされてなかったと書かれています。

 

f:id:foxcafelate:20201031162544p:plain

 

PCI DSSの専門家の1人として考えると、正直に言えば、ここは判断が結構難しい所です。おそらく非常に巨大なシステムだったと思いますので、私も監査等で提示される一部の証跡だけでチェックしていたとすれば、(ログのスコープの妥当性に気づかず)問題無いと判断したかも知れません。

フォレンジック調査の結果から言えば、ログチェックすべき点が抜け落ちていた、PCI DSS認定を継続している他社にとっても意識しておくべき点です。

 

ログの問題点について、(フォレンジック調査の結果として)2点指摘されています。

f:id:foxcafelate:20201031162836p:plain

 

最大のポイントは、データーベースにおける重要アクションが監視(ログ記録)対象外であった事です。

2点目は、データベースから全てのデータがダンプファイルとして持ち出される(生成される)部分について防御(=制限又は監視)してなかった点です。データベース全体の持ち出しは、2015年の段階からされていた様ですので、ここが制限または監視されていたとすれば、ここまで大型の漏えい事件にならずに抑え込めた可能性があります。

 

もう1か所、上のポイントの方が原因(脆弱ポイント)として大きいのですが、ここも監視しておくべきだったのでは、と思ったのが、データベースの暗号化されたテーブルへスクリプトでのアクセスです。

メンテナンス等の理由で、正常命令である事もあるかと思いますが、(クレジットデータを含む)データベースの全データを要求する様なスクリプト動作について、何も監視せず、アクセス出来ていた所は、やはり問題だったのかと思います。

f:id:foxcafelate:20201031163207p:plain

 

もう少し面白い内容がありそうな(歯ごたえがありそうな)通知書PDFですが、久々に英語をまじまじと読んで疲れてしまったのと、恐らく誤訳のボロが(普段機械翻訳を使いすぎなので・・・)出てきてしまうかと思いますので、この辺にしておきます。

無料で1,000アビオスを入手する方法(2020年12月1日まで) / 1,000 free Avios via – bizarrely – Star Alliance member Aegean Airlines (if you’re patient!)(転載)


 1,000 free Avios via – bizarrely – Star Alliance member Aegean Airlines (if you’re patient!)

そう、奇妙に見えるかもしれませんが、スターアライアンス加盟のエーゲ航空が、10分間の仕事と引き換えに1,000アビオスをプレゼントしたいと考えているのです!

他のマイレージプログラムも利用可能で、ユーロスターのポイントも加算されます。

残念なことに、エーゲ航空のルール変更により、これは必要以上に面倒なことになってしまいました。以下の私のプランのステージ3を行うには、12月まで待つ必要があります。

12月1日までの12日間、エーゲ航空では、Miles+Bonusスキームに登録した人全員に5,000マイルを無料で提供しています。回り道をすれば、これを1,000アビオスに交換することも可能です。

ステージ1: エーゲ航空のマイル+ボーナスアカウントが必要です。

それは非常に簡単です。エーゲ航空のウェブサイトのこのページにアクセスし、「登録」をクリックしてフォームに入力します。

ウェブサイトに登録するだけの「ベーシック」オプションではなく、デフォルトのMiles+Bonusアカウント開設オプションを選択します。

先週末までは、マイルは即時に計上されていました。下記をご参照ください。


しかし、エーゲ航空は今、ルールを変更しました。現在は1,000マイルを受け取り、12月15日までに残りのマイルを受け取ることができます。これが登録時に表示されるものです。


近々ギリシャに行く予定がある方は、5,000マイル+ボーナスマイルは国内線片道航空券との交換にも使えるので、取っておいた方がいいかもしれません。

Aviosや20ユーロのホテルバウチャーが欲しい方は、続きをお読みください。


ステージ2:Accor Live Limitlessのアカウントが必要です。

エーゲ航空は、ホテルのロイヤリティプログラム「Accor Live Limitless」との双方向の乗り継ぎパートナーである。アコーはノボテル、ソフィテル、イビス、ラッフルズ、スイスホテル、メルキュールなどを所有しています。

エーゲ航空のマイルは4:1の割合で2,000マイル単位でアコーライブリミットレスに移行されます。

アコーライブリミットレスのアカウントをお持ちでない場合は、アカウントを開設する必要があります。アコーのウェブサイトはこちら

次のステップ .... 欲しい報酬を決める

4,000エーゲ航空マイル+ボーナスポイントを移行すると、アコーライブリミットレスポイントが1,000ポイントもらえます。

すでにアコーライブリミットレスポイントを貯めている場合は、そのままにしておくとよいでしょう。アコーポイントを2,000ポイント貯めるごとに、次回のホテル予約で40ユーロの割引が受けられます。

それ以外の方は、アコーのアカウントでポイントを自動的に航空会社やクラブユーロスターに変換するように設定してください。

ここが重要なポイントです。Aviosが欲しい場合は、ブリティッシュ・エアウェイズではなくイベリア・プラスを選択する必要があります。イベリア航空のAviosへの移行率は1:1ですが、ブリティッシュ・エアウェイズのAviosへの移行率は2:1です。これは1,000アビオスを受け取るか、500アビオスを受け取るかの違いです。

イベリア航空の自動変換の設定は、アコーのウェブサイトのこのページで行うことができます。リワードポイントの変換」をクリックします。

イベリアへのオートコンバージョンには最低3,000ポイントが必要と表示されます。これは真実ではありません。以下は私のアカウントのスクリーンショットです。


各取引の後にアビオスが移動するのがわかります。私の妻のアカウントも同じように機能しています。

もしアコーが最低3,000ポイントの交換条件を課そうとした場合、1,000ポイントのアコーポイントが残ってしまいます。その場合は、40ユーロのバウチャーで2,000ポイントを獲得するか、イベリア航空への乗り換えで3,000ポイントを獲得するか、どちらかの方法で滞在してポイントを補充する必要があります。

ステージ3:エーゲ航空のマイル+ボーナスマイルの交換方法(12月15日に!?

12月15日までにAegeanの残高が5,000 Miles+Bonusマイルになります。

アコーライブリミットレスのメンバーシップ番号をお持ちのお客様は、Aegean Miles+Bonusマイルに交換することができます。

このページが必要です - リンクをクリックすることをお勧めします。このページが表示されます。


5,000マイル+ボーナスマイルのうち4,000マイルを交換したいとすると、このようになります。


私が変換できて、あなたができないのは、ルールが変わったからです。週末に一気に5000マイルを受け取りました。今は2回目のバッチのために12月15日まで待つ必要があります。

アコーにポイントが到着するまでにどのくらいの時間がかかりますか?

わからないわ 条件には6週間までと書いてあります。このオファーは12月1日に締め切られるので、私は実際に自分のポイントを受け取る前にそれについて書くことにしました。

私は日曜日にエーゲ海からの乗り換えを実行したが、まだ何も届いていない。アコーに到着してから、イベリア航空に到着するまでには、さらに数日かかりそうです。

イベリアプラスからは、「Convert My Avios」を使用してBritish Airways Executive Clubに移動することができます。ここでは、「Convert My Avios」の仕組みについて説明します。

もちろん、アコーがこの5,000ボーナスマイルに遡って制限を課そうとする可能性もあります。5,000マイルのサインアップオファーが12月1日で終了することを考えると、アコーはITを書き換えようとするのではなく、このままにしておくのではないかと思います。

結論

エーゲ海からの出国手続きを12月15日まで待たなければならないことを考えると、これはちょっと面倒なことだと思う。飛び込むかどうかはあなた次第です。

この記事では「1,000 Aviosを手に入れる」と見出しを付けましたが、1,000ポイントをアコーに残してホテルの割引に利用すると、よりお得になることを覚えておいてください。そのためには、滞在することで2,000ポイントを獲得する必要があります。

エーゲ航空にマイルを残してギリシャ国内線に使えばさらにお得ですが、現実的にはほとんどの読者には向かないでしょう。