今天介紹一下另一起入侵事件，這次入侵事件的黑客技術水平明顯要高於上次，作爲這次入侵事件的發現者，感觸頗多，由於已經離開該公司，避免對公司有什麼影響，公司名用代號替代。
詳細追查過程和相關敏感信息忽略。
B互聯網公司，在出現該入侵事件幾個月前，公司出現部分客戶手機號被盜情況，後續將客戶手機號做加密，但涉及面多，未完全做完，
歷史原因，有部分系統用的PHP的Tars框架開發，各種原因Tars維護很困難，準備做一下遷移處理。這時架構師和運維，開啓了Tars集羣一臺雲主機的公網IP權限，開了幾天，遷移處理完後，就關閉了，但就是這個看起來很簡單的操作帶來了巨大的後果。
研發一直在做庫表遷移，把表從原有的一個庫，分拆到其他實例上。當時做了一個SQL審計日誌分析系統，具體見：
用ELK分析每天4億多條騰訊雲MySQL審計日誌(1)--解決過程
這樣就可以知道這表還有哪些賬號調用，那些程序沒有改，改了有沒有改完等，方便研發快速做庫表拆分。
發現異常：
1，昨天下午某研發小組組長根ELK彙總查詢，反映有個賬號還有讀一個表，但查詢程序已經改完，無賬號讀取該表，但查詢ELK，的確還有查詢。
2，早上10:30左右，查看每日慢SQL，發現某個賬號查用戶表，一共幾百萬+條用戶數據，通過查詢先前導入的ELK的SQL執行日誌，
發現有賬號在凌晨導數據。
3，早上，旁邊的架構師說有臺雲主機發現有木馬，要查殺。
領導重視：
結合這幾天上面出現種種情況，再加上職業敏感性，我還特意和領導說了一下，有黑客入侵，旁邊的同事還說，想多了，那有那麼多入侵的事情。但有ELK這個工具的加持下，查詢下來的確發現很大異常，而且不只一次入侵，領導終於重視，讓我查數據庫方面情況，另外一個架構師同事查雲主機方面情況，彙報給公司。
查詢結論：
1，數據很有針對性，特別針對有查詢mobile字段的表。
2，特意查詢了有encrypt的字段，感覺是避開加密信息
select * from INFORMATION_SCHEMA.columns where COLUMN_NAME Like '%encrypt%'
3, 4天時間進行了3次入侵，有次還是從凌晨1點到持續到中午12點多，大白天工作時間也敢做，膽子比較大。
4，用了5個數據庫賬號來查詢數據
5, 4張包含手機號的敏感數據表被導出
同事還特意登陸了國外的暗網，看是否有賣我公司資料的信息，結果沒找到，可能發現的比較及時。
個人感觸：
1，感覺黑客水平高，一直沒想通雲主機沒有MySQL驅動，怎麼連到我們的數據庫
2，黑客怎麼在那麼短時間鎖定我們的雲主機，通過什麼漏洞進來的，怎麼把數據下載下去的。
感覺還是公司資料一直被盯上了，剛好有這個漏洞和誤操作給了機會
3，公司後來進行一系列的安全改進，將手機號等敏感信息加密，招專門的安全人才負責信息安全方面。