釣魚郵件日漸猖獗？教你辨識詐騙信件的實用方法

Posted on by

你是否曾在工作或生活中，突然收到一封語氣急促的 Email，內容看起來像是公司高層或熟識對象寄來的指示？例如最近在台灣相當常見的一種詐騙郵件，內容寫著：「因應工作需求，請你立刻建立一個公司專用的 Line 群組，請勿自行邀請任何成員，群組設立後將群組QR Code寄回本信箱。」

信件不長，語氣直接，寄件者名稱看起來也沒什麼問題，很多人第一時間的反應是「主管很急」，而不是懷疑。也正因如此，這類郵件才會一再得手。

事實上，這是一種典型的社交工程詐騙而非真正的公司內部溝通。它不需要駭進你的電腦，只要成功影響你的判斷，可能就足以造成損失。

為什麼詐騙 Email 看起來「不像詐騙」？

多數人對詐騙的印象，可能還停留在錯字很多、內容很假、一下就能看穿的那種信件。但現在的詐騙郵件，早就不是這樣。

攻擊者會刻意模仿公司常見的寫信方式，放上 Logo、使用正式職稱，甚至研究過企業組織架構，知道哪些人最有可能「照指示做事」。真正的破綻，往往不是外觀，而是細節。

其中一個最常被忽略的地方，就是寄件者的 Email 位址。顯示名稱可能寫著「董事長」或「CEO」，但實際信箱卻是免費信箱，或是拼字極為相近、卻不是公司正式網域的地址。只要稍微點開檢查，就能發現異常。

另外，這類信件常伴隨一種共同特徵：製造緊急感。內容會刻意簡短，不給你背景、不給你時間思考，只要你「立刻處理、私下完成、不要通知其他人」。一旦陷入緊張，就很容易跳過確認流程而落入陷阱。

用實際範例來看，該怎麼檢查一封 Email

很多人會說「要檢查 Email」，但真正收到信時，往往不知道該看哪裡。以下用幾個實際情境，帶你一步步看懂該怎麼判斷。

首先，可以從寄件者資訊開始看。例如你收到一封信，顯示名稱是「王大明｜董事長」。乍看之下是正常的寄件者，但當點開詳細資訊後，卻發現實際信箱是 ceo.company@gmail.com。即使對方自稱公司高層，只要不是公司正式網域寄出，就應該立刻提高警覺。許多仿冒 CEO 的詐騙信，正是利用「大家只看名字、不看信箱」這個習慣。

再來，是連結的檢查方式。假設信件內容寫著「請至公司內部系統確認」，底下放了一個看起來很正常的「前往系統」連結。這時請不要急著點擊，而是把滑鼠移到連結上，你可能會看到實際網址顯示為 https://bit.ly/xxxxx，或是完全陌生的網域名稱。真正的公司系統，通常會使用固定且熟悉的網址格式，如果連結刻意隱藏或與公司無關，就應提高警覺。

而信件中夾帶的附件。有些詐騙信會附上一個檔案，檔名可能叫做「付款明細.pdf」或「掃描文件.zip」，內容通常會搭配一句「請盡快確認」。這類附件的危險之處在於，它們看似正常檔案，卻可能只是外表偽裝，實際上潛藏惡意程式。因此遇到可疑的附件時，應透過惡意程式掃描或是沙箱進行確認沒有問題後才可開啟。

如果你想再多確認一步，可以查看郵件的來源資訊，也就是所謂的郵件標頭（Header）。以 Gmail 為例，只要點擊「顯示原始郵件」，就能看到這封信實際是從哪個郵件系統寄出的。你不需要看懂所有技術欄位，只要確認寄送來源是否來自公司既有的郵件服務即可。如果公司平常使用的是內部郵件系統，卻發現來源是國外免費郵件服務，這通常就不是正常信件。

最後，也別忽略信件內容本身的合理性。以近期流行的「仿冒 CEO 指派員工開立群組」詐騙為例，這類信件通常不會有詳細背景，只會告訴你「現在立刻做某件事」，並刻意強調事情很急、不要聲張。然而正常的公司溝通，很少會在完全沒有上下文的情況下，要求你立刻繞過流程處理敏感事項。

真正的問題不只是技術，而是人的判斷

這類詐騙之所以難防，是因為它攻擊的不是系統，而是人。防毒軟體、防火牆、垃圾郵件過濾，確實能擋下一部分，但只要有一封成功進入收件匣，最後的判斷仍然落在人身上。

也因此，單靠「提醒大家要小心」其實不夠。很多人在平時聽得懂，但在忙碌、壓力大、被要求立刻處理事情的情境下，還是會失誤。

從「看過案例」到「實際演練」的差別

比起單純宣導，更有效的方式，是讓使用者實際看過、甚至親身經歷詐騙情境。例如透過各種社交工程詐騙的範例信件，讓人知道這些信件真實長什麼樣子，而不只停留在宣導階段。

對企業或組織而言，進一步的做法則是透過「社交工程模擬演練」，在不造成實際風險的前提下，模擬仿冒 CEO、財務、 IT 或是系統通知的郵件，檢測員工是否會點擊、回信或照指示行動，再搭配教育訓練進行改善。這種方式，往往比單向宣導更能有效提升警覺度。

執行社交工程模擬演練的方式有委託廠商或自行操作，兩者各有優缺點。委託廠商通常能快速導入成熟的範例與流程，適合沒有專責人力或經驗的組織；若完全自行操作，則需要投入較多時間設計情境、撰寫範例信件與整理結果，對內部資安與管理能力也有一定門檻，但相對地執行上能更加彈性。

無論採取哪一種方式，真正重要的不只是「有沒有做演練」，演練後是否能回頭檢視問題、補強教育訓練，才能讓人員在下一次收到可疑郵件時，能夠更快察覺並做出正確判斷。

結語：多一眼確認，就是最實用的防線

詐騙 Email 不會消失，只會隨著時事與情境不斷變化。但只要你在收到信件時，願意慢下來，多看一眼寄件者、多確認一步內容合理性，大多數攻擊其實都能被擋在第一關。

技術可以防一半，真正補上最後一塊拼圖的，仍然是人的判斷與意識。

By Mike

資安法／ISMS 啟動第一步，原來可以這樣開始

Posted on by

還在煩惱資訊安全管理要從哪裡下手嗎？面對資通安全管理法或 ISO 27001 等資安標準，許多人得到長官的指派/指示後，一開始都會感到無從下手，甚至不知道這是甚麼。但其實不用怕！只要抓住幾個重點，就能順利展開第一步。以下提供三個簡單步驟，帶你輕鬆啟動公司的資訊安全，提高整體資安防護力與員工資安素養。

找出主管機關/適用範圍

搞清楚規定是誰定的、管到誰。也就是確認這項資安法規或標準由哪個單位主管，以及我們公司是否在適用範圍內。

  • 資通安全管理法

舉例來說，在台灣推行的《資通安全管理法》由數位發展部主管，規範對象如下：

  • 公務機關：中央、地方機關（構）或公法人，但不包括軍事機關及情報機關。
  • 特定非公務機關：關鍵基礎設施提供者、公營事業、特定財團法人或受政府控制之事業、團體或機構。

一般民間企業若未被明文列為規範對象，雖不具法定強制性，仍可依實際風險與治理需求，自主比照資安法精神與國際標準進行導入，以提升資安治理成熟度與對外信任。

  • ISO 27001:2022 (ISMS)

若組織以取得 ISO/IEC 27001認證為目標，須明確界定資訊安全管理系統（ISMS）的導入範圍，包括但不限於：

  • 業務範疇：涉及哪些產品、服務、營運等核心業務
  • 組織邊界：涵蓋哪些部門、團隊、供應商等。
  • 資訊資產與系統：納入哪些重要資訊、應用系統、伺服器或資料庫等資產。

考量首次導入 ISMS 時，雖涵蓋全公司能帶來的效益最大，但也可能導致：

  • 導入成本過高
  • 管理與稽核複雜度增加
  • 人力與資源負荷過重

因此，實務上多採風險導向原則，優先將核心業務與高風險來源納入 ISMS 管理範圍，例如：

  • 客戶或個人資料處理系統
  • 營運關鍵資訊系統
  • 對公司營運影響重大的資訊資產

        需注意，若被主管機關要求符合資安法，核心資通系統有要求在限定時間內完成導入 CNS 27001 或 ISO 27001 等資訊安全管理系統標準、其他具有同等或以上效果之系統或標準，或其他公務機關自行發展並經主管機關認可之標準，於三年內完成公正第三方驗證，並持續維持其驗證有效性。

確認義務與最低要求

不論是法律還是國際標準，都會規定一些基本義務和最低資安措施。我們需要細讀相關條文或標準條款，搞清楚有哪些必做事項，然後逐項檢視自家現況是否符合。

以下是常見且必要的基本作業項目，可提供各位作為關鍵字與實務推動參考：

  • 建立資安政策
  • 建立資通安全組織
  • 實施資產界定與盤點
  • 實施風險評鑑與控管
  • 建立事件通報機制
  • 實施教育訓練
  • 實施存取控制
  • 定期執行營運持續演練
  • 落實資訊安全檢測
  • 定期執行內/外部資安稽核

如果事前把這些「最低標準」摸透，就能優先處理最重要的事項，確保不會漏掉法規硬性規定，也為後續進階的資安措施打好基礎。

建立專案小組

團隊合作來破關！資訊安全不是一個人的戰役，無論跨部門的專案團隊，或是成立資安部門都非常重要。

若是在導入初期，建議從各部門挑選對資安有興趣或相關職能的代表，組成資安推動小組，並推選一位專案經理來統籌計畫執行。有了專案小組後，可以召開資安啟動會議，向全體同仁宣示公司導入資安管理的決心與目標，同時確認需要投入的資源（人力、預算、工具等）。透過明確的分工與合作，大家各司其職，才能把資安的各項措施落實到位。團隊齊心，才能事半功倍地提升公司整體的資訊安全水準。

萬丈高樓平地起，資安治理也是從基礎一步步累積。從搞清楚適用的規範、了解基本義務，到組建專案團隊，這三步就像是啟動資安管理的地基。有了穩固的第一步，後續不論是進行風險評估、制定政策還是推行員工訓練，都會更有方向感。現在就行動起來吧，別讓資安只是口號，讓我們一起把它落實在日常工作中！

如果您在導入過程中需要專業協助，我們公司也提供完整的資安顧問服務與資安治理與落實平台SAR(Security Accreditation & Regulation)。SAR被打造的目的就是協助各位更好的進行資安治理，無論是初次導入或是長期維護，SAR都會以任務導向為所有的待辦項目設計獨立的任務卡。讓所有人員能更輕鬆的從制度規劃、風險評估到落地執行，一路陪伴企業從建立規範到符合法規/政策、最後到可持續運作的資安治理體系。

【參考資料】

By Jared

OWASP Top 10 for LLM Applications (下篇)

Posted on by

在上一篇(參考：OWASP Top 10 for LLM Applications (上篇)，我們深入探討了LLM01~LLM05的主要風險，相信各位對LLM應用的潛在威脅已有更清晰的認識。在本篇中，我們將繼續解析OWASP Top 10 for LLM Applications中的LLM06~LLM10，進一步拆解其攻擊手法與實際案例。

■ LLM06: Excessive Agency 過度代理

攻擊手法

當LLM系統功能過多、權限過高或自主性過強，在面對惡意攻擊者、受污染的程式或Prompt Injection時，可能執行非預期的行為，進而影響機密性（Confidentiality）、完整性（Integrity）與可用性（Availability），危及系統內所有可存取的資源。

案例 – AssitAI助手

讓我們用一個情境來說明「過度代理」的風險程度。AssitAI是一個基於 LLM開發的企業內部助手，旨在協助各部門完成他們的工作，如協助整理報表、查找資料、分析資料等。

然而，若AssitAI並未對使用者的請求進行控管，且自身被授予存取公司資料的權限超自身的業務範圍時，攻擊者可透過結合prompt injection的技巧要求AssitAI對公司的機敏資料進行存取、更新、甚至刪除。這將導致公司的機敏資料外洩，甚至財產損失。從AssitAI的情境中可以看出，過度代理可能帶來嚴重的安全風險。當LLM應用具備過多的存取權限，且缺乏適當的請求控管，攻擊者便能誘使系統執行未經授權的操作。

■ LLM07: System Prompt Leakage 系統提示洩漏

攻擊手法

當系統指令或資訊存在未預期暴露的敏感內容（如憑證、連線資訊、系統設定等），攻擊者可透過內容分析，推測系統缺陷，進而識別防護機制漏洞或權限管理不當，造成進一步攻擊風險。

  1. 憑證與密鑰洩露：系統回應中包含授權憑證，可能導致未授權存取
  2. 系統資訊暴露：錯誤訊息或日誌中顯示內部架構，助長攻擊面分析
  3. 過濾機制洩露：回應內容揭露LLM防禦邏輯，使攻擊者得以規避

案例 – Flowise遭竊取system prompts等資訊

Flowise是一個drag-and-drop的LLM開發工具，其可讓開發者快速整合企業內部的LLM架構。並且可透過AI代理進行任務自動化執行，通常Flowise會整合AWS Bedrock、Confluence、Github或OpenAI API等外部服務。

圖片來源：https://flowiseai.com/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Flogo-color-high.e60de2f8.png&w=256&q=75

在2024年，資安服務商Legit針對959台Flowise建構的伺服器，並且發現其中有45%的伺服器存在繞過憑證驗證的弱點CVE-2024-31621。然而透過此弱點，Legit從438台伺服器中取得了Github的access tokens、OpenAI API keys與Flowise相關的密碼、設定值、system prompts提示等。這些洩漏資訊足以讓駭客輕而易舉存取企業內部大部分的資訊，甚至導致企業或客戶的機敏資料外洩。

■ LLM08: Vector and Embedding Weaknesses 向量與嵌入弱點

攻擊手法

在Retrieval Augmented Generation (RAG)架構下，LLM透過檢索外部知識庫來增強回應內容。然而，若向量生成、儲存或檢索機制存在漏洞，攻擊者可藉此影響模型行為，可能導致輸出操控、敏感資料洩露，甚至影響決策準確性。

案例 – ConfusedPilot侵蝕Copilot決策模型

2024年，有一個針對Copilot這類模型Retrieval-Augmented Generation (RAG)的新型態攻擊手法ConfusedPilot問世，該系統是由Symmetry Systems 執行長 Mohit Tiwari 教授所領導的研究團隊揭露。

圖片來源：https://confusedpilot.info/logo.jpg

ConfusedPilot攻擊目的在於將Copilot變成一個搞破壞的助手。首先，攻擊者會對LLM用於決策判斷的相關文件或簡報等進行汙染。一旦LLM對這些污染文件進行查詢時，便會影響LLM的判斷並僅回覆使用者經受汙染的資訊。然而，這些文件內容並無法透過刪除便能解決威脅，其所造成的汙染已侵蝕了LLM的決策模型。這也表明，LLM模型的向量與嵌入已遭受汙染。

■ LLM09: Misinformation 誤導

手法

使用者對LLM過度信任(Overreliance)，在開發、業務決策、學習、法律諮詢等情境下，可能因錯誤資訊而做出不當決策，進而暴露於風險之中。其中「幻覺」(Hallucination)是主要成因之一，即模型生成內容看似合理，但實際上是憑空編造，可能導致錯誤建議、誤導性決策，甚至影響企業與個人安全。

案例 – 美國律師受LLM「幻覺」影響

近期，LLM在法律領域的應用引起了社會大眾的關注，特別在LLM回覆資訊時，會產生大量虛構案例，即是所謂的「幻覺」。而有數名律師因對內容過度信任而導致面臨制裁。以下是相關案例的彙整：

在2025年，美國知名個人傷害律師事務所Morgan & Morgan的兩位律師，在對沃爾瑪公司的案件中引用了LLM所產生的虛構案例，因故將會面臨制裁。並且在同年2月，其中一位律師承認使用了AI程式，並為此錯誤道歉。過去兩年中，至少有七起類似案例，法院對律師引用AI生成的虛構案例表示關切或進行紀律處分。

■ LLM10: Unbounded Consumption 無約束的資源消耗

攻擊手法

LLM在推理過程中若未設定適當限制，可能陷入無限資源消耗模式，進而成為拒絕服務攻擊(DoS)的目標。攻擊者可透過過量請求或複雜計算，讓系統資源耗盡，導致服務品質下降、營運成本增加，甚至進一步影響模型與資料的安全性。

案例 – Red Hat Enterprise Linux AI遭受DoS攻擊

2024年，Red Hat Enterprise Linux AI(未知版本)被發現存在一個被分類為問題性的漏洞。這個漏洞影響了ilab Model Serve組件中的vllm JSON web API。當攻擊者於參數best_of中輸入未知不當內容時，webAPI可成功實現阻斷服務攻擊攻擊(DoS)。

圖片來源：https://www.redhat.com/rhdc/managed-files/rhel-ai-hero-graphic_0.png

本項攻擊的重點在於，此API主要用處理LLM的聊天內容，並以一個best_of參數從多個選項中取得最佳的結果。然而，一旦參數設定較大，會出現API無法正確運作，造成處理耗時或資源耗盡的威脅。主因為LLM並未適當地對系統資源進行控管，導致LLM被賦予消耗大量資源的權限，使系統無法正常運作，影響其他正常使用者的訪問服務。

透過本篇文章，我們完整解析了OWASP Top 10 for LLM Applications的後五項風險（LLM06~LLM10）。至此，我們已經完整梳理了LLM應用可能面臨的十大風險，幫助企業與開發者在導入LLM技術時做好安全防護。然而，LLM技術仍在快速演進，新的安全問題也可能隨之出現。未來，我們將持續關注LLM的發展，並分享更多與LLM安全相關的最佳實踐，確保大家能夠在創新應用的同時，降低風險，安全地釋放LLM的潛力。

【參考資料】

By Jared

OWASP Top 10 for LLM Applications (上篇)

Posted on by

根據上一篇的內容(參考：LLM 架構解析)，想必各位對LLM模型的架構已經有了初步的認識。本期我們將深入解析OWASP Top 10 for LLM Applications中的10項資安風險與弱點。

或許大家迫不及待想要一次了解所有威脅，但為了讓各位能夠更透徹地理解每個資安風險，我們將逐一剖析每項威脅的攻擊手法與實際案例。今天，我們將率先介紹LLM01~LLM05，其餘五項風險則將在下一篇揭曉！

LLM01: Prompt Injections 提示詞注入

攻擊手法

攻擊者可透過精心設計的LLM提示詞(prompt)來竊取敏感資訊或影響模型的判斷，進而執行惡意行為。這類攻擊可分為兩種模式：

  1. 直接提示詞插入 (Direct Prompt Injection)
    • 此類攻擊是利用惡意提示詞影響LLM的回應邏輯，讓模型執行不當行為。
    • 攻擊者可能試圖透過提示詞繞過安全限制，甚至存取後端系統的敏感資訊。
  2. 間接提示詞插入 (Indirect Prompt Injection)
    • 此類攻擊是針對LLM參考的外部資料來源(如網頁、文件)進行內容篡改，讓模型在讀取該資訊時產生非預期的行為。
    • 攻擊者可在這些資料來源中注入惡意內容，從而影響LLM的回應，甚至進一步存取或控制後端系統。

案例：Jailbreaks

Jailbreak是一種突破大型語言模型用途限制的技術，當輸入繞過模型內建的安全限制，其將會輸出本不應提供的資訊，如非法內容、濫用指引或其他違規資訊。其中，已經被發現的Jailbreak prompt已多達數十種，以下提供Evil-Bot Prompt範例供參考。

當模型被上述的Prompt誘導進入如「EvilBOT」的角色時，它可能會開始提供本應受限制的資訊，進一步加劇濫用風險。詳細越獄結果可參考下圖，每當攻擊者提出LLM原先無法處理或受限的請求時，模型起初會回應無法滿足該請求的說明，但隨後便透過角色扮演「EvilBOT」的方式，提供違法資訊，從而繞過安全機制。

圖片來源：https://gist.github.com/sertdfyguhi/4e291776fe95b975becf468e762a28e7?permalink_comment_id=4516928

LLM02: Sensitive Information Disclosure 敏感資訊揭露

攻擊手法

LLM在許多應用場景中可能涉及機敏訊息，如：

  1. 個人識別資訊(PII)：姓名、身分證字號、聯絡資訊等。
  2. 財務資料：信用卡資訊、銀行帳戶、交易紀錄等。
  3. 健康紀錄：病歷、醫療診斷、保險資料等。
  4. 商業機密：公司內部文件、專利技術、客戶資料等。

如果未妥善管理，這些機敏資訊可能會因未經授權的存取而遭到洩露，導致：

  1. 敏感資料與機密資訊的暴露
  2. 隱私權侵害(Privacy Violation)
  3. 知識產權(IP)侵犯

這類風險通常發生在LLM agent將機敏資料回傳至application service 或plugins/extensions，導致機密資訊被意外存取或利用。

案例 – OmniGPT資料外洩

OmniGPT是一個由多個熱門且常見的LLM模型所構建而成，如下圖所示。

圖片來源：https://omnigpt.co/

在2025年2月，BreachForums的論壇上有人聲稱掌握了OmniGPT大量的機敏資料，包含30K的使用者信箱和手機號碼與34M的聊天訊息，並且外洩的資料也包含了大量的API keys、憑證與帳單等內容，詳細資訊可參考下圖。

圖片來源：https://cyble.com/blog/omnigpt-leak-risk-ai-data/

根據Cyble的研究團隊調查結果，這些資料分成了四份文件，分別為：

  1. File.txt：記錄了使用者上傳檔案的連結，並且部分內容屬於機敏資料。
  2. Messages.txt：包含了使用者與OmniGPT聊天所使用的prompt，並且部分內容屬於機敏資料。
  3. User_Email_Only.txt：儲存了使用者的信箱地址。
  4. UserID_Phone_Number.txt：記載了大量使用者帳號信箱與聯絡電話。

其中在File.txt和Messages.txt的資料中儲存了tokens、API keys、credentials、帳號密碼等關鍵資訊，這導致惡意攻擊這可進一步利用這些資訊發動攻擊。並且，User_Email_Only.txt與UserID_Phone_Number.txt中的資料看似無害，但這些資料可被駭客用於進行釣魚攻擊、身分竊取或是社交工程等。

LLM03: Supply Chain 供應鏈威脅

攻擊手法

LLM供應鏈的每個環節都有可能成為攻擊目標，影響訓練資料、模型完整性、部署平台，甚至導致不正確的回應、安全漏洞或系統故障。這些風險可能來自：

  1. 軟體層面：程式碼漏洞，如Python內建函式的安全弱點、外部或供應鏈中的API套件、搭建LLM的平台等。
  2. 機器學習模型層面：由供應鏈所提供的參考資料或訓練資料已被污染，如惡意或低品質資料影響模型學習、受汙染或竄改的資料儲存系統。

這些問題可能讓攻擊者操控LLM的行為，進而影響企業運作或造成資訊洩露。

案例 – DeppSeek tokens竊取

DeepSeek作為2025年間備受矚目的LLM模型，其一上線即引起全球的關注。

圖片來源：https://www.deepseek.com/

2024年12月26日，DeepSeek發布了DeepSeek-V3版本，但僅在發布後數天內，駭客就取得了該模型的完整存取權限。根據Nexus-AI的說明，本次攻擊的駭客被稱為LLM Hijackers。此次攻擊是由於Nexus-AI雲端託管平台的零時差漏洞所致，駭客利用這一漏洞盜取了tokens，並通過這些tokens合法地存取DeepSeek-V3的完整功能。Nexus-AI還表示，此次事件已威脅到DeepSeek-V3的部分功能。

此外，駭客還在黑市上販售這些tokens以獲取非法利益，這些tokens的價格低至30美元，可以提供30天的訪問權限。這些非法販售的tokens在地下論壇和某些平台上廣告，吸引了大量買家。此案例主因為供應鏈中的Nexus-AI雲端託管平台存在漏洞，致使DeepSeek遭受攻擊。

LLM04: Data and Model Poisoning 資料和模型中毒

攻擊手法

在預訓練(Pre-training)、微調(Fine-tuning)或嵌入(Embedding)過程中，惡意攻擊者可針對內容發動攻擊，導致模型性能下降、產生偏見與有害內容，甚至植入漏洞與後門，最終使使用者與下游服務暴露於安全威脅之中。

案例 – 醫療用資料集The Pile汙染

2025年1月，Nature Medicine發布了一篇最新有關如何利用資料汙染嚴重影響LLM模型輸出結果的正確性。

圖片來源：https://www.nature.com/articles/s41591-024-03445-1

首先，研究團隊針對醫療領域常用於訓練的The Pile資料進行攻擊，然而他們僅汙染0.001%的訓練資料為錯誤的醫療訊息，便成功使得1.3B的參數模型增加了7.2%的錯誤率。並且，團隊嘗試將汙染資料提高到0.01%進行實驗，此時錯誤內容則飆升到了11.2%。這項研究表明，即使是極小比例的資料汙染，也能顯著影響大型語言模型的準確性。更令人擔憂的是，進行這種攻擊的金錢成本非常低。研究團隊指出，僅需約5美元的成本便能生成足夠的錯誤資料來進行有效的資料汙染攻擊，這對於依賴這些模型進行醫療診斷和決策的應用程序尤為重要。

LLM05: Improper Output Handling 輸出處理不當

攻擊手法

當LLM處理完資料後，未經驗證或過濾即直接回傳資訊給使用者或下游服務，可能導致以下風險：

  1. 跨站腳本攻擊(XSS)
  2. 跨站請求偽造(CSRF)
  3. 伺服端請求偽造(SSRF)
  4. 提權攻擊
  5. 遠端程式碼執行(RCE)

這類攻擊可能使使用者與下游服務暴露在嚴重的安全威脅之中。

案例 – ChatGPT遭受駭客組織濫用

2024年，OpenAI發布了有關ChatGPT遭到濫用的研究報告，其中說明了駭客組織利用ChatGPT輔佐惡意活動進行，如資料蒐集或生成惡意程式，這些行為屬LLM模型對於輸出的管理與過濾不當。

圖片來源：https://zh.wikipedia.org/zh-tw/OpenAI

接下來，我們以大陸「SweetSpecter」與伊朗「CyberAv3ngers」駭客組織的案例進行說明。

  • SweetSpecter：該組織利用了ChatGPT進行惡意攻擊的準備。此次攻擊涵蓋的對象包含中東、非洲與亞洲的政府機關與OpenAI員工。經深入調查該組織在ChatGPT的使用者行為，發現SweetSpecter利用多個ChatGPT輔佐進行了惡意程式的腳本與弱點分析等。
  • CyberAv3ngers：該組織透過ChatGPT針對工業控制系統(ICS)與可程式邏輯控制器(PLCs)進行攻擊。經過調查分析，該組織利用ChatGPT協助了偵查、取得預設帳號密碼與協助開發惡意程式等。

從上述案例可以看出，駭客組織已經將LLM技術作為輔助工具，以提升攻擊的精確度與自動化程度。這些案例反映出LLM在輸出管理與內容過濾上的挑戰，尤其當駭客透過繞過限制或提示工程的方式，誘導模型生成有害內容時，現有的防範機制仍存在漏洞。

在本次粉絲文中，我們介紹了OWASP Top 10 for LLM Applications的前五項安全風險（LLM01~LLM05），並透過實際案例剖析了可能的攻擊方式。這些風險揭示了LLM於應用時的潛在風險，提醒開發者與使用者在部署LLM時必須提高警覺。然而，這僅僅是LLM安全挑戰的一部分，還有更多潛在風險值得我們關注。在下一篇粉絲文中，我們將進一步解析剩餘的五大風險（LLM06~LLM10），幫助大家全面掌握LLM應用的安全防護要點。

【參考資料】

By Jared

LLM 架構解析

Posted on by

隨著ChatGPT、Claude、Copilot等人工智慧工具的廣泛應用，許多領域已與大型語言模型深度融合，顯著提升整體服務品質與營運效能，為各行各業帶來前所未有的變革與發展機遇。然而，資訊技術的發展總伴隨著資訊安全的潛在風險，這已成為不可忽視的重要議題。

國際知名的資訊安全組織OWASP(參考：OWASP Top 10 2021入門介紹)在2023年即啟動了Large Language Model Applications計畫，專門研究大型語言模型(LLM)應用可能面臨的資安風險，類似於之前粉絲文中所介紹Web風險弱點。該計畫聚焦於各領域在LLM模型開發、設計與應用階段時應關注的威脅與資安弱點。目前，該計畫最新的版本 – OWASP Top 10 for LLM Applications 2025，已於2024年11月17日正式發布。

為了讓大家更清楚了解LLM的潛在風險，本系列內容將分為三個部分進行介紹：

  1. LLM架構解析：首先，我們將介紹LLM的基本架構，幫助大家理解其運作原理，包括使用者輸入、模型運行、外部服務交互以及模型更新等關鍵流程。
  2. OWASP Top 10 for LLM Applications (上篇)：接著，我們將剖析OWASP Top 10 for LLM Applications中的LLM01~LLM05，詳細說明每項風險的定義、攻擊手法、實際案例與對應的防範措施。
  3. OWASP Top 10 for LLM Applications (下篇)：最後，我們將進一步解析 LLM06~LLM10，補充更多與LLM應用安全相關的風險，確保大家能夠全面認識LLM的潛在威脅，降低LLM系統的安全隱患。

隨著LLM技術的快速發展，資訊安全風險也隨之提升。希望透過本系列的介紹，幫助大家更有系統地理解LLM資安議題，進而強化應用防護，確保系統穩定與安全！

LLM架構

從下圖中，我們可以看到一個簡易的LLM架構。儘管整體框架看起來較為複雜，但我們先認識每個元件的功能與意義，其核心運作方式將會透過簡單的情境來理解。

  • End User：LLM模型的使用者。
  • Application Service：Core/GreenField: 供使用者的應用程式服務，如ChatGPT的服務介面。
  • LLM Production Services：
    • LLM Automation(Agents): 負責調用、管理、交互。
    • LLM Model: 負責內容理解、分析、推理、生成。
  • Plugins/Extensions：LLM串接的應用功能。
  • Downstream Services：根據LLM結果，進一步處理或應用於其他系統。
  • Training Dataset & Preprocessing 
    • Training Data: 用於建立模型基本能力，包括語言理解、分析、推理、生成之資料集。
    • Fine-tuning Data: 用於微調模型的資料集，以適應特定任務或行業需求。
  • External Data Sources：提供模型即時查詢的資料、文件、知識庫。

接下來，將為大家講述一個直觀的案例，幫助大家更輕鬆地掌握LLM的基本概念與應用方式。

  1. 使用者輸入：End user透過application service(ChatGPT、Claude、Copilot)輸入對話內容(prompt)，類似我們開啟ChatGPT頁面進行提問的方式。
  2. 模型運作：Application service會將問題傳送至LLM production services，模型隨後執行理解、分析、推理與生成等處理程序。根據需求，模型可能會採取以下處理方式：
    • 無需額外擴充功能：系統直接在LLM production services內部生成回覆，並回傳至application service，供使用者查看結果。
  • 需額外擴充功能：若LLM需要額外工具來處理請求，如計算、程式碼執行，則可能透過Plugin/Extension機制進行額外運算，完成後回傳結果至 Application Service。
  • 需下游服務：若系統需要存取外部資料，如企業資料庫、核心應用程式或網站，則可透過plugin轉發請求至 downstream services。
  1. 模型訓練與微調：Training Dataset & Preprocessing是 LLM 訓練與優化的核心流程，其資料來源可分為：
    • 使用者輸入的內容可能會被收集來優化未來模型版本，但不會直接影響當前模型。
    • 外部資料庫，如維基百科、新聞、學術論文等，可作為 LLM 訓練時的基礎資料。

透過本篇文章，我們解析了LLM的基本架構，從使用者輸入到模型運行，再到外部服務交互與模型更新，讓大家對LLM的運作方式有了更清晰的理解。然而，除了技術架構外，LLM應用的安全性也是不可忽視的重要課題。在下一篇文章中，我們將聚焦於OWASP Top 10 for LLM Applications，探討LLM應用可能面臨的前五大安全風險，並解析對應的攻擊手法。

【參考資料】

By Jared

持續合規監控 (Continuous Compliance Monitoring)

Posted on by

近年來，資訊安全已不再是大型企業與政府機關所面臨的挑戰，中小型企業(Small and mid-sized businesses; SMBs)受到的威脅也日益嚴峻，其中威脅最為顯著的面向如下表：

面向說明
營利虧損營運中斷、勒索贖金、客戶流失。
法律訴訟個資外洩或服務停擺引發集體訴訟。
高額罰則GDPR 可罰年度營收 4%，資安法亦有重罰上限。
品牌信譽受損一次事故足以造成股價、聲譽重挫。

法規、標準或指引

為能更好的應對威脅，各領域都有相關的法規、標準或指引制約，如下所示為常見組織與規範：

  • 資通安全管理法（台灣）：政府機關與關鍵基礎設施的強制性框架
  • ISO/IEC 27001：國際資訊安全管理系統標準
  • HIPAA：美國醫療隱私與安全規範
  • CMMC：國國防部供應鏈成熟度模型
  • GDPR：歐盟一般資料保護規則

導入資訊安全相關管理規範除提升企業資安防護能量外，更重要的一點在於多國監管與跨境合作的企業日趨頻繁。企業若具備法規遵循、標準認證、風險控管與事件應變等措施，更能充分展現其在資安防護上的成熟度，進而在全球市場中提升信賴度與競爭力。

何謂持續合規監控（Continuous Compliance Monitoring）

持續合規監控是一種針對合規管理的解決方案，其採取即時監控機制與數據分析，持續追蹤組織的運作狀態與合規性。這意味著，企業能在第一時間偵測到異常或偏差的發生，並立即採取應變措施，避免風險潛藏與擴張。

換句話說，持續合規監控能讓企業隨時掌握自身現況，使整體的管理能更為主動與靈活，降低風險的發生機率、補救成本、名譽受損等。

合規管理：傳統合規 vs 持續合規監控

在組織政策的合規管理上，以下將透過不同面向對 (I)傳統合規 與 (II)持續合規監控 進行分析：

核心價值

雖然持續合規需要較高的前期投入，但它能全面提升組織的資訊安全防護與事件響應能力，帶來下列關鍵效益：

  • 最小化風險與罰則：快速偵測並修正缺口，將損失降至最低。
  • 提高安全性與資料保護：持續監控可降低攻擊成功率。
  • 簡化複雜作業與稽核準備：持續彙整佐證資料，稽核「隨到隨過」。
  • 強化公司聲譽與客戶信賴：即時合規狀態可公開佐證治理成熟度。
  • Real-time法遵儀表板：管理階層即時掌握 KPI 與缺口，支持策略決策。

持續監控挑戰

導入「持續合規監控」並非一蹴可幾，它要求企業同時在制度、技術與組織文化層面持續精進。以下列舉實務上最常遇到的痛點：

  • 控制項繁多：多套法規交疊，映射與維護複雜。
  • 持續優化負荷：需隨威脅情勢調整與落實控制項，工作量大。
  • 人力／資源壓力：高頻監控與落實控制項帶來持續負荷。
  • 人為疏忽：大量繁複控制項目，難以避免執行人員疏失。
  • 專業門檻：熟悉法規、控制項、落實方式等對人員專業需求高。

簡化挑戰的實踐路徑

以下為導入持續合規管理時可參考實踐方式：

  • 控制項對映與最佳化：透過匹配資安法、上市上櫃公司資通安全管控指引、ISO 27001、CMMC 等多套規範，一次對映至現行流程，找出重疊控制項並消除冗餘，避免多頭管理與重工。
  • 結合法遵工具精確落實：導入 GRC／合規平台，持續監控控制項執行情形，以工具取代人工，降低人力負荷與錯漏風險。
  • 即時多通道通知：透過系統、Teams、Email、Line、Telegram等管道即刻通知與告警，確保相關人員在黃金時效內處理。
  • 細化落實指引：將每項控制項拆解為明確任務與 SOP，附範例與執行步驟，讓尚缺經驗或專業背景的人員也能按表操課，降低人才門檻並提升執行一致性。
  • 集中佐證管理：將所有稽核佐證集中保存，並加上時間戳與版本控管，隨時支援抽查與秒級彙報。除簡化內外部稽核流程，亦能隨時向管理層或利益關係人展示資安防護成熟度。

本公司已針對「持續合規管理」打造產品與顧問方案，涵蓋控制項對映、即時監控、自動化與落實指引等。如需進一步了解或安排示範，歡迎隨時與我們聯絡，我們將提供最適合貴組織的導入建議與支援。

【參考資料】

By Jared

紅隊工具介紹-Cobalt Strike

Posted on by

近年來業界對於資安防護的需求日益增長，針對企業相關的檢測也逐漸從針對特定範圍的檢測擴展至企業整體全方位的紅隊演練。


所謂紅隊演練是模擬真實攻擊者對目標進行攻擊，以測試安全防禦和應急反應的訓練活動。紅隊成員利用多種技術和策略，試圖入侵系統並竊取資料，為了能夠達成目的，大多進行演練的公司會自行開發或使用相關的產品，而Cobalt Strike便是其中一套強力的工具。

Cobalt Strike是一款專為紅隊演練與滲透測試而設計的強大工具，廣泛應用於模擬攻擊和安全演練中。它最初由Raphael Mudge開發，旨在提供一個全面的紅隊作業平台，以幫助安全專家模擬真實的攻擊行為，從而評估目標系統的弱點和防禦措施。

紅隊人員可以透過其多功能的Command-and-Control（C2）框架輕鬆部署和控制各種攻擊向量，如惡意軟體、社交工程學攻擊和滲透測試工具，並且Cobalt Strike還提供了強大的漏洞利用工具，能夠利用目標系統中的漏洞進行特權升級和持久性存取。

在實際應用中，Cobalt Strike通常用於模擬典型的APT（進階持續性威脅）攻擊，例如偽造電子郵件、利用已知漏洞進行內網滲透以及橫向移動，其高度可定制化的特性使得使用者能夠根據具體需求定製攻擊模式，以最大程度地模擬現實世界的威脅。

此外，Cobalt Strike還提供了強大的報告和分析功能，用於評估測試的結果並生成專業的測試報告，這些報告不僅可以幫助使用者了解其安全防禦機制的可能風險，還能提供改進和加強安全策略。

總結來說，Cobalt Strike作為一個多功能的紅隊演練工具，普遍用於模擬攻擊和滲透測試。它提供了多種攻擊向量和功能，包括社交工程、漏洞、持久化存取、命令與控制等，以支援團隊協作和即時攻擊模擬，還能夠提供深入的攻擊模擬和分析功能，並幫助安全專家測試和增強企業的安全防禦。

By Stanley

什麼是SSL憑證？

Posted on by

在現今數位時代中，網站的安全性至關重要，SSL（Secure Sockets Layer）憑證是用於網站加密的一種安全技術，它能保護使用者在網站上傳輸的數據。當網站使用 SSL 憑證後，瀏覽器網址欄會顯示「HTTPS」並且出現鎖頭圖示，這意味著該網站傳輸資訊是經過加密的。SSL憑證的類型根據其保護的網域範圍，可劃分為以下三種：

單域名憑證（Single-Domain Certificate）

單域名憑證專門用於保護單一域名，不包含任何子域名。它僅適合用於只需要保護一個網站的情境，如www.example.com。

多域名憑證（Multi-Domain Certificate）

多域名憑證又稱SAN（Subject Alternative Name）憑證，允許一張憑證同時保護多個不同的域名，甚至可以跨不同的主域名。例如，您可以使用同一張多域名憑證來保護www.example.com、shop.example.net以及blog.example.org。

萬用憑證（Wildcard Certificate）

萬用憑證適合用來保護同一主域名及其所有子域名。當您擁有一個主域名並包含多個子域名時，萬用憑證是一個便捷的選擇。例如，*.example.com萬用憑證可以保護子域名如shop.example.com、blog.example.com、support.example.com等。但不能保護sub.blog.example.com或example.net等二級子域名或其他域名。

SSL憑證種類與比較

單域名憑證多域名憑證 (SAN憑證)萬用憑證
保護範圍單一個域名多個不同的域名主域名與 所有一級子域名
適用場景單一域名網站多個域名的網站具大量子域名的網站
擴充性每個域名都需要各自的憑證可彈性新增多個域名只要是一級子域名皆可適用
私鑰存放位置單一伺服器多個套用此憑證的伺服器多個套用此憑證的伺服器
成本低高中

如何申請SSL憑證？– Let’s Encrypt

申請SSL憑證有多種方法，本篇文章將簡介Let’s Encrypt進行憑證申請的流程。Let’s Encrypt是提供免費SSL憑證的開源機構，讓網站管理員能輕鬆快速地取得基本的SSL憑證。透過 Let’s Encrypt申請憑證時，主要分為兩大步驟：

  1. 證明網域所有權：Let’s Encrypt會要求申請者在網站的某個路徑上放置一個特殊的驗證文件，並進行隨機數簽名，以此證明申請者擁有該網域的管理權限。
  2. 憑證頒發：一旦網域所有權通過驗證，Let’s Encrypt就會生成一份SSL憑證。這份憑證包含該網域的公開金鑰，並由Let’s Encrypt的簽章進行驗證，確保憑證的真實性。

透過這兩個步驟，網站管理員可以輕鬆為網站啟用HTTPS，增強資料傳輸的安全性。

總結來說，SSL憑證對於網站安全至關重要，而Let’s Encrypt 提供了一個方便、免費的選擇。希望本篇文章能幫助您理解SSL憑證的種類以及申請流程，並提升網站安全性！

[參考資料]

[1] Let’s Encrypt 的運作原理，

https://letsencrypt.org/zh-tw/how-it-works/，2019-10-18

[2]SSL 憑證：憑證是什麼？為什麼您必須使用憑證？以及要如何取得憑證呢，https://www.ithome.com.tw/pr/142541，2021-02-01

By Gary

什麼是社交工程?

Posted on by

前言：

        在現代，由於通訊及網路設備的普及，幾乎人人都有智慧型手機，隨時隨地都可上網。這些科技的進步為世界帶來許多便利，這也衍伸出許許多多資訊安全的問題，而在這樣資訊爆炸的環境也助長駭客的成長，他們會利用各式各樣的技術或手法來達成他們想要的目的，今天就要來介紹其中一樣攻擊手法——社交工程。

什麼是社交工程：

社交工程就是，利用人們的心理活動，誘使人們進行某些操作，以達到竊取資訊或是植入惡意軟體等等的目的，例如：在路上撿到一個隨身碟，裡面可能就包含有惡意程式，當你因為好奇裡面有什麼檔案而插入電腦並點開時，你的電腦可能就被植入惡意程式，這將會導致電腦中的資料被竊取，甚至是電腦被有心人士控制。

社交工程的攻擊手法層出不窮，常見的攻擊手法包含：

  1. 假冒正常網站：有心人士利用知名網站，並製造出與其網站相似的內容，讓使用者難辨真偽，例如 www.yahoo.com 變成 www.yαhoo.com，如果不仔細觀察的話很難發現區別，如果使用者不小心進入到假冒的網站，並且輸入登入資訊，那麼不法人士就取得了使用者的帳號密碼，如果是銀行帳戶的話，他將可以把使用者的金錢盜領一空。
  2. 惡意廣告：現在的網頁中充斥著各式各樣的廣告，這些廣告中也是有著真真假假，其中廣為人知的惡意廣告可能就是「恭喜中獎！恭喜您抽中XXXX」這類的廣告，如果你點擊並填寫姓名手機電子郵件的話，他們就能取得個資，並透過各種方式對你進行詐騙。
  3. 釣魚郵件：不法人士透過偽裝成各式各樣的電子郵件，例如：社群推播、公司內部訊息等等，誘使使用者點開電子郵件並點擊連結或下載附件，這將會觸發駭客潛藏的惡意程式並自動下載到使用者的裝置中，這些惡意程式可能會竊取裝置內資料或是側錄設備的使用過程，這樣駭客就能取得使用者的各式敏感資訊進行下一步的攻擊。
  4. 魚叉式攻擊：前面說到釣魚郵件通常是撒網捕魚的類型，誰上鉤就攻擊誰，魚叉式則不同，他具有高度針對性，其對象通常是某個機構，目的與釣魚郵件一樣，誘使使用者點擊電子郵件中的連結或是下載附件，以達到竊取資料或植入惡意程式的目的。
  5. 商業電子郵件詐騙（BEC詐騙）：又稱變臉詐騙，通常從歹徒入侵高階主管郵件帳號或合作廠商帳號做為起點。通常是經由鍵盤側錄的惡意程式或式網路釣魚取得，歹徒將會建立高度仿真的公司內部或相關企業的電子郵件，誘騙目標提供資料。入侵電子郵件後，歹徒將監控並試圖找出轉帳或是要求轉帳的對象，並發送偽造的電子郵件要求匯款至歹徒控制的銀行帳戶中。

如何防範社交工程攻擊：

社交工程攻擊通常都是透過網站或是電子郵件，並且利用人性的弱點進行詐騙，所以如果要防止受到攻擊，要從人身上做起防護：

  1. 不要點擊來路不明的連結
  2. 不要直接開啟郵件內的附件，須先由防毒軟體掃描後，確保無惡意程式後再進行開啟。
  3. 不要直接點擊郵件內的連結，如果有連結需要操作，應透過其他管道連線正確官網確認後再進行操作。

By Dennis

零信任

Posted on by

零信任是近幾年流行的資安話題，你可能已經看過關於介紹零信任的文章，今天就讓三甲科技再帶你重新簡單地溫習這個名詞吧！

在傳統的企業網路架構上，以往我們都是透過防火牆區隔內部與外部網路，將外部網路視為威脅進行阻隔，而內部網路則視為安全區域，不做過多的防護或認證機制。然而，倘若內部網路任何一台設備遭受惡意入侵，攻擊者很有可能藉此在內部網路橫向擴散，整個內部資料遭竊取、設備遭加密勒索或是網路癱瘓。再者，技術的發展與疫情的爆發，伴隨的是網路使用習慣或基礎架構的轉變，例如雲端服務、BYOD或是居家辦公等。在這些轉變下，內部網路存在的設備已不像以前那麼單純，過往的安全架構未必仍可達到足夠的防護。

        基於上述的問題，零信任便是為了解決這些問題而發展的一個概念。單從字面上來看，或許能猜出它的大意，但所謂的「信任」指的又是什麼？在前面所描述的情境，內部資料遭受竊取的首要條件是內部網路其中一台設備被入侵，但為何僅僅一台設備被入侵就能取得整個內部的資料？就是因為內部其他的服務「信任」這台被入侵的設備，而沒有做任何驗證或限制，導致駭客可隨心所欲，想去哪就去哪。因此，零信任便是提倡即使在內部網路中，也不輕易信任任何設備，需要先經過一些驗證才可存取或提供資料。如此一來，就算有惡意人士可以入侵企業的內部網路，想存取其他的服務或設備也會變得更加困難，進而降低影響的範圍與損失。

        前兩段我們說明了零信任想解決的問題與它的概念，而到底要做哪些事才能邁向零信任？NIST在2020年8月發佈SP 800-207標準文件，內容針對零信任架構進行說明，並提供導入零信任架構的建議步驟。其中第一步即為「評估」，應先針對企業資產、資料流、系統、人員、工作流程等細節進行盤點調查。在完整了解組織的營運狀況後，便可擬定適當的零信任架構調整計畫或政策方針，接下來則包含風險評估與政策發展、佈署與作業。

By Mike

【參考資料】

[1] 【Wired 硬塞】到底什麼叫「零信任」？答案其實取決於你想聽到什麼，https://www.inside.com.tw/article/24908-what-is-zero-trust，2021-09-22

[2] 【搞懂零信任，從理解NIST SP 800-207著手】打造以零信任原則的企業網路安全環境，https://www.ithome.com.tw/news/145709，2021-07-21

[3] Zero Trust Architecture https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf, 2020-08