WorkOS lộ dữ liệu app bán hàng nội bộ, Chainstack lộ password hash và node credential, vậy hãng xác nhận liên hệ với ARTEX tới mức nào

Tuần đầu tháng 11 năm 2026, WorkOS công bố ngày 2 tháng 11, Chainstack công bố ngày 3 tháng 11, cái tên ARTEX thì xuất hiện khắp nơi nên nhiều người đọc gộp hai vụ thành một câu chuyện. Mức xác nhận thì khác hẳn: bản tin WorkOS xác nhận vụ lộ dữ liệu và khung AI hỗ trợ tấn công nhưng không nêu tên ARTEX, tên này chỉ có qua kênh CEO và thông báo gửi khách hàng dạng có khả năng; Chainstack xác nhận vụ lộ dữ liệu production nhưng cũng không nêu tên ARTEX, liên hệ ARTEX ở vụ này chỉ là đánh giá của báo chí.

Tóm tắt: WorkOS lộ liên hệ công việc, lịch sử tài khoản và quan hệ, trích đoạn cuộc gọi, hỗ trợ và Slack, cộng metadata vận hành, hãng nói chưa có bằng chứng production bị động tới. Chainstack lộ tên tổ chức, tên người giữ tài khoản, email thành viên và password hash, node credential phải coi như đã lộ và xoay ngay. Mức xác nhận ARTEX ở mỗi vụ khác nhau, xem bảng mục 4.

1. WorkOS, app nội bộ của đội bán hàng bị vào còn production thì hãng nói chưa có bằng chứng bị động tới

Vụ WorkOS nhẹ hơn về dữ liệu dùng để đăng nhập, nhưng lại nặng về dữ liệu dùng để lừa đảo.

1.1. Hãng công bố những gì trong bản tin ngày 2 tháng 11

Bản tin chính thức của WorkOS ngày 2 tháng 11 ghi hãng phát hiện truy cập trái phép ngày 30 tháng 10 vào ứng dụng của đội bán hàng và đội hướng tới khách hàng, với 4 nhóm dữ liệu: liên hệ công việc, lịch sử tài khoản và quan hệ, tóm tắt cùng trích đoạn cuộc gọi, hỗ trợ và Slack, cộng metadata vận hành. Bản tin còn mô tả một khung tấn công hỗ trợ bởi AI dùng để tự động hóa trinh sát và thử khai thác, nhưng không nêu tên cụ thể nào. Về production, hãng chỉ nói chưa có bằng chứng production hay dữ liệu nền tảng khách hàng bị động tới, điều tra vẫn tiếp diễn và hãng sẽ liên hệ trực tiếp khách hàng bị ảnh hưởng.

1.2. Những gì bản tin không nói, và tên ARTEX xuất hiện ở đâu

Bản tin chính thức không nêu tên ARTEX, cách xâm nhập ban đầu hay số tổ chức bị ảnh hưởng. Tên ARTEX xuất hiện ở hai kênh khác: CEO Michael Grinich nêu ARTEX trên X và Hacker News kèm phát ngôn production vẫn an toàn, và thông báo gửi khách hàng qua bản đăng lại, trong đó hãng viết vụ tấn công có khả năng do ARTEX thúc đẩy. Chữ có khả năng là điểm mấu chốt, lược nó đi thì đánh giá dạng khả năng biến thành kết luận chắc nịch. Bản đăng lại còn nhắc mốc 16 giờ 39 phút UTC ngày 30 tháng 10, dữ liệu Salesforce và Snowflake, địa chỉ gửi thư của công ty, cùng lưu lượng từ IP ở Hong Kong và Trung Quốc, những chi tiết chỉ có ở kênh phụ. Một độc giả trên Hacker News đã hỏi về vector xâm nhập ban đầu và di chuyển ngang, và câu hỏi đó vẫn chưa có câu trả lời từ hãng.

1.3. Vì sao dữ liệu quan hệ khách hàng lại thành mồi lừa đảo tốt

Tác giả Gabriel Anhaia viết trên DEV rằng tên và email chỉ cho ra tin lừa đảo chung chung, còn ghi chú cuộc gọi và trích đoạn Slack cho ra tin lừa đảo biết rõ tích hợp nạn nhân đang dùng, tên quản lý tài khoản và lỗi đã báo tháng trước, và hãng tự cảnh báo điều này. Với độc giả Việt Nam làm việc với vendor nước ngoài, bài học nằm ở những gì đội mình từng viết vào ticket hỗ trợ và kênh chat chung với vendor, vì những dòng đó có thể nằm trong tay kẻ khác sau một vụ lộ ở phía vendor. Lời khuyên đi kèm, như rà soát kênh chung với vendor hay đưa mọi thay đổi cấu hình SSO qua dashboard đã quen thay vì qua link trong tin nhắn, là suy luận của tác giả Anhaia chứ không phải khuyến nghị của WorkOS, nhưng mình đồng tình vì lập luận có lý.

2. Chainstack vào từ môi trường dev ngày 26 tháng 10, tới production ngày 29 tháng 10, password hash và node credential là điểm nặng nhất

Sang vụ Chainstack thì mức nặng đổi hẳn, vì dữ liệu lộ ra còn có thể dùng để đăng nhập và vận hành node.

2.1. Diễn biến theo trang sự cố chính thức ngày 3 tháng 11

Trang sự cố chính thức của Chainstack ngày 3 tháng 11 kể một câu chuyện kéo dài hơn khung mà báo chí tóm tắt, vì hãng ghi cả mốc vào dev từ trước khi chạm tới production. Kẻ tấn công ở trong hệ thống tổng cộng 5 ngày, trong đó có 2 ngày đã vào production, rồi mới bị phát hiện và cắt truy cập, và khoảng lặng đó mới là điều đáng hỏi chứ không phải riêng từng mốc ngày. Hãng nói thêm dịch vụ vẫn chạy bình thường, node, console và API không bị sửa đổi, và hãng không lưu chi tiết phương thức thanh toán, nhưng hãng chưa trả lời kẻ tấn công đã xem những gì ngoài database tài khoản, cũng chưa giải thích vì sao đường từ dev sang production lại đi được.

Wiz ghi khung Chainstack từ ngày 29 tới ngày 31 tháng 10, trong khi hãng công bố xâm nhập dev từ ngày 26 tháng 10, và mình lấy timeline của hãng làm chuẩn, vì khung của Wiz bỏ qua giai đoạn dev.

2.2. Vì sao password hash và node credential nặng hơn dữ liệu quan hệ khách hàng

Dữ liệu Chainstack công bố gồm tên tổ chức, tên người giữ tài khoản, email thành viên tổ chức và password hash, cộng node credential mà hãng nói chưa có bằng chứng bị đọc nhưng vẫn coi như đã lộ và yêu cầu khách hàng xoay. Nhìn vào hậu quả thực tế thì một bên là dữ liệu giúp kẻ lừa đảo viết tin giỏi hơn, một bên là dữ liệu có thể dùng để đăng nhập và vận hành node nếu xoay không kịp, và password hash càng nhạy vì nhiều người dùng trùng mật khẩu ở nhiều nơi. Hãng yêu cầu coi node credential như đã lộ dù chưa có bằng chứng bị đọc, vì chờ có bằng chứng bị đọc rồi mới xoay thì đã muộn, và hãng nhận trách nhiệm trực tiếp cùng tính năng xoay credential không gián đoạn. Mình không bịa phản ứng khách hàng Chainstack trên mạng xã hội: các lần tìm kiếm ngày 3 tới ngày 4 tháng 11 chỉ trả về bài báo lại vụ việc, không có bài đăng đáng tin của khách hàng kể trải nghiệm xoay key hay nhận email thông báo.

2.3. Checklist xoay credential cho khách hàng Chainstack

Việc gấp nhất là đổi mật khẩu Chainstack, kể cả ở những nơi khác dùng trùng mật khẩu đó, vì mật khẩu trùng ở nơi khác cũng nằm trong diện rủi ro. Khi mật khẩu đã đổi xong, cần xoay node credential qua console ngay, mà không phải lo đứt dịch vụ vì endpoint cũ vẫn chạy tới khi xoay xong. Xong hai việc đó rồi thì tạo lại platform API key nếu có dùng, đồng thời giữ cảnh giác với lừa đảo, vì hãng nói hãng không bao giờ hỏi mật khẩu, token hay key.

3. ARTEX là một framework pentest đa agent viết bằng Go, và ba điều ARTEX không phải

Tới đây mới nên giải thích ARTEX, vì độc giả đã thấy hai vụ việc trước rồi.

3.1. ARTEX hoạt động ra sao theo mô tả của Google và Mandiant

Theo mô tả của Google và Mandiant, ARTEX là nền tảng pentest và điều khiển chỉ huy tấn công đa agent dùng mô hình ngôn ngữ, viết bằng Go, có console web nhúng Next.js, sáu sub-agent chuyên biệt, dùng API của model frontier và model mã nguồn mở, và dịch mục tiêu cấp cao thành lệnh máy. Một nhà phát triển Trung Quốc công bố công cụ này trên GitHub tháng 7 năm 2026, nó thắng thử thách red team Agent+ của Baidu tháng 9 năm 2026, rồi chuyển sang mã nguồn đóng ngày 8 tháng 10 năm 2026 sau khi code đã có hơn 12.000 fork, và các biến thể gồm ScopeWeaver và ARTEX PRO vẫn lan truyền. Google liệt kê các khả năng quan sát được gồm trinh sát Active Directory tự động, leo thang đặc quyền, thu thập key lưu trữ Azure, tổng hợp và triển khai webshell tùy chỉnh, và đây là mô tả kỹ thuật của Google về các vụ hãng quan sát, chứ không phải bước đi trong vụ WorkOS hay Chainstack.

3.2. Chatbot viết mã độc là chuyện khác, và ARTEX cũng không phải một lỗ hổng duy nhất

Chatbot trả lời bằng văn bản và đoạn code theo yêu cầu, còn ARTEX xâu chuỗi nhiều bước trinh sát và khai thác bằng tool với tốc độ lặp lại, nên một bên dừng ở câu trả lời, một bên tự chạy tiếp. Google nói kỹ thuật vào vẫn cũ, gồm thông tin đăng nhập bị đánh cắp, hệ thống chưa vá và quyền cấp quá rộng, và Wiz nói không có một lỗ hổng hay dependency duy nhất nối mọi vụ tháng 10 lại với nhau, vì phần lớn các vụ vẫn đang phân tích. ARTEX vì vậy là khung điều khiển chạy nhiều kỹ thuật cũ với tốc độ mới, vá một lỗ hổng duy nhất không chặn được nó. Điều thứ ba, ARTEX chưa từng chạy tự trị hoàn toàn, vì Google ghi nhận kẻ tấn công phải đưa credential bị đánh cắp cho ARTEX rồi ra lệnh chạy các bước tiếp theo, và CrowdStrike ghi nhận người vận hành vẫn can thiệp ở các điểm quyết định quan trọng.

3.3. ARTEX chưa được xác nhận là thủ phạm ở cả hai vụ này

Bản tin WorkOS không nêu tên ARTEX, tên chỉ có ở kênh CEO trên X và Hacker News cùng thông báo gửi khách hàng dạng có khả năng qua bản đăng lại, và trang sự cố Chainstack không nêu tên ARTEX hay nhóm tấn công hay kỹ thuật, liên hệ ARTEX ở vụ Chainstack chỉ tới từ đánh giá của The Hacker News về điểm trùng lặp với chiến dịch rộng hơn. Cách gắn nhãn của AgentBeam đáng bắt chước: vụ WorkOS đã xác nhận nhưng liên hệ ARTEX chưa kiểm chứng.

4. Bốn mức xác nhận cần tách ra khi đọc tin hai vụ này

Bảng dưới đây tách bốn mức xác nhận mà tin tức hay gộp thành một câu duy nhất rồi đọc như đã chắc chắn, để anh em đọc tới đâu biết tới đó mức nào đã chắc, mức nào mới chỉ là đánh giá.

4.1. Bảng đã xác nhận, đánh giá, có khả năng qua kênh phụ, vẫn chưa biết

Wiz ghi khung Black October với ít nhất 9 nền tảng AI developer công bố sự cố trong tháng 10, phần lớn liên quan credential bị truy cập, nhưng Wiz thừa nhận phần lớn vụ vẫn đang phân tích, nên không được phép nói tất cả là một chiến dịch ARTEX duy nhất khi bằng chứng chưa tới đó. Mình đồng tình với tinh thần thận trọng của Netcrook, đừng coi mọi lần truy cập trái phép như vụ trộm dữ liệu đã hoàn tất, nhưng cập nhật bằng phát ngôn của CEO.

4.2. Số liệu của Google, Microsoft, Wiz và CrowdStrike thuộc về vụ của chính họ

Google ghi đợt thực thi nén từ 2 tới 25 giây, 27 sự kiện trong 23 giây khi thăm dò quyền AWS, 240 sự kiện log khi thử thực thi lệnh từng phần qua API của máy chủ Linux Weaver OA, 491 URL webhook luân phiên, và hơn 110.000 đối tượng Active Directory bị liệt kê. Microsoft, trong vụ STORM-0940 và xâm nhập chuỗi cung ứng ConnectWise, ghi thử đăng nhập vào hơn 2.250 tenant Microsoft 365, đợt password spray từ ngày 10 tới ngày 14 tháng 10 tạo hơn 151.000 lần thất bại nhắm 327 tài khoản thuộc 8 tổ chức, đỉnh 2.900 lần mỗi phút, và không có lần xác thực thành công nào. Wiz, trong các vụ hãng quan sát suốt tháng 10, ghi hơn 60 biến thể route SSO bị thử bằng cùng một token giả trong 2 phút, khoảng cách trung vị giữa các lần thử đăng nhập đúng 1 giây, phiên kéo dài từ 24 tới 30 giờ, và đa số lần thử đều thất bại. CrowdStrike, trong chiến dịch VAPOR PANDA từ ngày 17 tháng 10 kéo dài 11 ngày, ghi hơn 200 tổ chức tại ít nhất 14 quốc gia bị nhắm, hoạt động sau xâm nhập được xác nhận tại 9 tổ chức, và một vụ tiêu thụ khoảng 1,4 tỉ token đầu vào cho agent lập kế hoạch.

4.3. Hai điểm vênh nhỏ cần nêu ra thay vì chọn một bên

Về thời gian thì Wiz ghi khung Chainstack từ ngày 29 tới ngày 31 tháng 10, trong khi Chainstack công bố kẻ tấn công đã vào môi trường dev từ ngày 26 tháng 10, nên đọc khung của Wiz mà không đọc thêm mốc dev thì sẽ thiếu mất giai đoạn đầu. Về tên ARTEX thì CEO Michael Grinich nêu tên này trên X và Hacker News, trong khi bản tin chính thức của WorkOS không nêu tên ARTEX, nên tên ARTEX ở vụ WorkOS vẫn ở kênh khác, không cùng mức với vụ lộ dữ liệu mà bản tin đã xác nhận.

5. Từng nhóm người nên làm gì, theo thứ tự khẩn cấp

Giờ thì tới phần anh em hỏi nhiều nhất, mình thuộc nhóm nào và việc nào làm trước.

5.1. Khách hàng Chainstack, việc khẩn cấp làm trước

Với nhóm này thì không có chỗ cho việc chờ đợi, vì password hash và node credential đã lộ là thứ kẻ khác có thể dùng ngay nếu xoay chậm, nên anh em làm theo thứ tự đã nêu ở mục 2.3, từ việc gấp nhất xuống việc tiếp theo, đừng đảo thứ tự để làm việc dễ trước.

5.2. Khách hàng WorkOS, việc cần làm khi chưa biết mình có bị ảnh hưởng hay không

Khách hàng WorkOS thì thứ tự ngược lại, vì hãng sẽ liên hệ khách hàng bị ảnh hưởng, nên việc đầu tiên là chờ thông báo trực tiếp để biết mình có nằm trong diện bị ảnh hưởng hay không. Trong lúc chờ, mọi yêu cầu bất ngờ đều phải kiểm chứng bằng kênh quen thuộc, kể cả khi nó nhắc tới đồng nghiệp thật hay cuộc trò chuyện hỗ trợ thật, vì những chi tiết thật đó là thứ dữ liệu lộ ra cung cấp cho kẻ lừa đảo. Rồi rà soát những gì đội mình từng dán vào kênh chung với vendor và ticket hỗ trợ, và xoay mọi credential còn sống tìm thấy trong đó, và mọi thay đổi cấu hình SSO thì đi qua dashboard đã quen, không qua link trong tin nhắn.

5.3. Người vận hành tool nội bộ, khóa tool phụ như khóa production

Vụ WorkOS cho thấy ứng dụng go to market, tool bán hàng, marketing và hỗ trợ, có thể thành mục tiêu thật, nên người vận hành tool nội bộ coi nhóm tool này như production mà khóa. Việc cần làm gồm kiểm tra source map và file cấu hình đang công khai hay không, giám sát các đợt đăng nhập thất bại hàng loạt, tạo tài khoản bất thường, thay đổi quyền và credential, và dùng credential ngắn hạn cùng quyền tối thiểu theo 5 lớp phòng thủ của Mandiant gồm cô lập control plane, credential ngắn hạn, quyền tối thiểu, phân đoạn và phát hiện hành vi. Nhận xét tool của đội bán hàng thường được khóa lỏng hơn production là suy luận từ vị trí của ứng dụng, dùng làm giả thuyết để đặt câu hỏi chứ không phải nguyên nhân đã xác nhận của vụ WorkOS.

6. Vì sao agent vẫn nguy hiểm dù còn thô sơ và ồn ào, và vì sao chính sự ồn ào đó giúp đội phòng thủ

Google và Mandiant đánh giá khung tấn công tự trị hiện tại còn ở giai đoạn đầu, thô sơ và gây ồn ào nhưng vẫn thành công.

6.1. Tốc độ và độ bền thay đổi điều gì so với hacker ngồi tay

Hacker ngồi tay thử từng đường rồi nghỉ, agent thử nhiều đường cùng lúc, tự sửa lỗi và thử lại suốt phiên từ 24 tới 30 giờ không nghỉ, và hai bên khác nhau ở nhịp làm việc chứ không ở kỹ thuật vào, vì kỹ thuật vào vẫn là credential bị đánh cắp, hệ thống chưa vá và quyền cấp quá rộng như Google nói. Bằng chứng tốc độ gồm đợt thực thi nén từ 2 tới 25 giây của Google, đợt password spray đỉnh 2.900 lần mỗi phút của Microsoft, và khoảng cách trung vị giữa các lần thử đăng nhập đúng 1 giây của Wiz, và Wiz ghi đa số lần thử đều thất bại, tức là agent không giỏi hơn ở từng lần thử, agent chỉ bền hơn ở chỗ thử mãi không mệt.

6.2. Con người vẫn chọn mục tiêu và đưa chìa khóa

Con người vẫn ở trong vòng lặp, chỉ là vai trò đã dời lên cao hơn. Theo Google, kẻ tấn công phải tự đưa credential bị đánh cắp cho ARTEX rồi ra lệnh cho nó chạy các bước tiếp theo. CrowdStrike thì ghi nhận người vận hành vẫn can thiệp ở các điểm quyết định quan trọng, và một đội nhỏ chạy nhiều vụ song song.

6.3. Ồn ào là dấu vết để săn, nếu đội phòng thủ biết săn theo cụm hành vi

Tốc độ và độ bền để lại dấu vết lớn, và trong các vụ Google quan sát thì ngoài những con số ở mục 4 còn có khoảng 400 KB kết quả truy vấn qua khoảng 20 câu lệnh, volume 100 GB và đĩa root mở rộng lên 60 GB để chuẩn bị lấy dữ liệu, và hơn 500 request thăm dò tên file và đuôi file trên các thư mục web. Wiz cảnh báo các user agent gây nhiễu nếu săn từng chỉ báo độc lập, nên đội phòng thủ phải săn theo cụm hành vi lặp lại, ví dụ một loạt lần thử đăng nhập cách nhau đúng 1 giây kèm thăm dò SSO và thử token giả. Đội phòng thủ làm được ngay là triển khai đủ kín 5 lớp phòng thủ của Mandiant và săn theo cụm hành vi lặp lại.

7. Những gì vẫn chưa rõ, và độc giả nên theo dõi tiếp ở đâu

Còn lại là những câu hỏi chưa có câu trả lời, để anh em biết mình đang chờ cái gì ở các cập nhật tiếp theo.

7.1. Danh sách câu hỏi còn mở ở cả hai vụ

Ở WorkOS, hãng chưa công bố số tổ chức bị ảnh hưởng, cách xâm nhập ban đầu, di chuyển ngang sau khi vào, và kết quả pháp y độc lập. Ở Chainstack, hãng chưa công bố tên thành phần bên thứ ba làm đường vào, kẻ tấn công đã xem những gì ngoài database tài khoản từ ngày 26 tới ngày 31 tháng 10, vì sao đường từ dev sang production lại đi được, và kết quả pháp y độc lập. Chưa rõ chung cho cả hai vụ là tên nhóm tấn công, và phản ứng trực tiếp của khách hàng Chainstack vì chưa tìm thấy dữ liệu thật, nên mình để trống chỗ đó. Chainalysis công bố ngày 30 tháng 10 một vụ xâm nhập dùng kỹ thuật agentic nhưng không nêu tên ARTEX. DIVD bị xâm nhập ngày 21 tháng 9 qua hai zero-day Zammad là một vụ agentic riêng biệt, không gắn tên ARTEX trong nguồn đã đọc, nên cả hai đều không dùng làm bằng chứng cho WorkOS hay Chainstack.

7.2. Theo dõi ở đâu và cập nhật sẽ thay đổi kết luận nào

Nguồn chuẩn để theo dõi tiếp là trang bản tin WorkOS và trang sự cố Chainstack mà hãng gọi là nguồn tin chuẩn, vì mọi cập nhật về phạm vi ảnh hưởng, kết quả điều tra và hướng dẫn xoay credential sẽ xuất hiện ở đó trước tiên. Nguồn bối cảnh là cập nhật của Google và Mandiant, Microsoft và Wiz về chiến dịch ARTEX nói chung, với lưu ý cập nhật chiến dịch chung không tự động thành bằng chứng cho hai vụ này. Nếu hãng công bố thêm, phần cần sửa đầu tiên là bảng phân loại ở mục 4, vì một công bố mới có thể chuyển một ô từ vẫn chưa biết sang đã xác nhận, hoặc chuyển liên hệ ARTEX từ đánh giá sang xác nhận.

Kết lại

Thiệt hại của hai vụ khác nhau, WorkOS là dữ liệu quan hệ khách hàng phục vụ lừa đảo tiếp theo, Chainstack là password hash và node credential cần xoay ngay, và mức xác nhận về ARTEX cũng khác nhau ở mỗi vụ, WorkOS có tên ARTEX qua kênh CEO và thông báo gửi khách hàng dạng có khả năng, Chainstack chỉ có liên hệ ARTEX ở mức đánh giá của báo chí. Việc làm ngay thì tùy nhóm của anh em: khách hàng Chainstack xoay credential theo thứ tự ở mục 5, khách hàng WorkOS chờ thông báo trực tiếp và kiểm chứng mọi yêu cầu bất ngờ, người vận hành tool nội bộ khóa tool phụ như khóa production. Giữ được ba ranh giới này thì lần tới anh em sẽ khó bị một tiêu đề gộp hai vụ thành một rồi đọc như đã chắc chắn dắt đi hơn.

Nguồn tham khảo

• Bản tin an ninh WorkOS: https://workos.com/security/bulletins/october-30th-2026-data-security-incident
• Trang sự cố Chainstack: https://chainstack.com/security-incident-nov-2026/
• The Hacker News về Chainstack: https://thehackernews.com/2026/11/chainstack-reports-production-systems.html?m=1
• Google và Mandiant về ARTEX: https://cloud.google.com/blog/topics/threat-intelligence/artex-and-friends-enter-agentic-offensive-frameworks
• Microsoft về STORM-0940: https://www.microsoft.com/en-us/security/blog/2026/10/21/storm-0940-uses-artex-agentic-ai-connectwise-supply-chain-compromise/
• Wiz về ARTEX: https://www.wiz.io/blog/artex-in-the-wild-storm-0940-expands-targeting-of-it-and-software-vendors
• Wiz về Black October: https://www.wiz.io/blog/black-october-for-ai-developer-platforms
• The Hacker News về VAPOR PANDA: https://thehackernews.com/2026/10/chinese-hackers-use-ai-powered-artex-to.html
• CSO về VAPOR PANDA: https://www.csoonline.com/article/4243816/armed-with-ai-hackers-target-endpoint-security-blind-spots-raising-stakes-for-cisos.html
• Bài phân tích của Gabriel Anhaia: https://dev.to/gabrielanhaia/an-ai-attack-framework-got-into-workoss-sales-tool-it-held-customers-slack-excerpts-4m4c
• Bản đăng lại thông báo gửi khách hàng của WorkOS: https://static.rdintel.com/news/item/hn/50345712
• CyberPress về WorkOS: https://cyberpress.org/hackers-ai-powered-attack-framework/
• RuntimeWire về WorkOS: https://runtimewire.com/article/workos-sales-tool-breach-artex-ai-agent
• Chainalysis về vụ ngày 30 tháng 10: https://www.chainalysis.com/blog/security-incident-october-30/
• DIVD về vụ ngày 21 tháng 9: https://csirt.divd.nl/cases/DIVD-2026-00014/
• Netcrook về cách đưa tin breach: https://netcrook.com/written_article?slug=ai-tooling-breach-story-data-trail-murky&lang=en
• AgentBeam về timeline tháng 11: https://agentbeam.com/blog/november-2026-attacks-timeline