Ngày 18 tháng 8 năm 2026
Các doanh nghiệp đã dành nhiều năm để tăng cường bảo mật “cửa trước” bằng các phương pháp như SSO, MFA, mã truy cập (passkeys) và mô hình Zero Trust. Tuy nhiên, mọi chương trình quản lý danh tính vẫn cần có một lộ trình khôi phục. Khi người dùng bị mất thiết bị hoặc bị khóa tài khoản, tổ chức phải quyết định xem nên thiết lập lại MFA, cấp thông tin đăng nhập mới hay liên kết một thiết bị mới.
Điều thú vị là, việc khôi phục tài khoản có lẽ là khu vực nguy hiểm nhất trong bề mặt tấn công, nhưng lại hiếm khi nhận được sự quan tâm tương xứng. Kẻ tấn công không phải lúc nào cũng cần phải vượt qua xác thực đa yếu tố (MFA) trực tiếp khi chúng có thể thuyết phục bộ phận hỗ trợ kỹ thuật hoặc quy trình khôi phục tài khoản bỏ qua cơ chế này.
Nếu việc khôi phục phụ thuộc vào các sự kiện đã biết, mã nguồn có thể chia sẻ hoặc phán đoán của một tác nhân, thì thực chất đó là việc xác minh những gì ai đó đã hay biết – chứ không phải liệu người đúng có thực sự có mặt hay không.
Cách thức khôi phục tài khoản thực sự diễn ra như thế nào hiện nay
Trước khi tìm hiểu cách thức quá trình phục hồi bị tấn công, chúng ta nên làm rõ cách thức mà phần lớn các tổ chức thực sự quản lý quá trình này.
Trong một doanh nghiệp điển hình, một nhân viên bị sa thải có hai con đường để quay trở lại làm việc.
Tự đặt lại mật khẩu (SSPR): nhân viên xác nhận một thông tin mà họ biết hoặc một vật mà họ sở hữu: câu hỏi bảo mật, mã số nhân viên hoặc mã xác thực dùng một lần được gửi đến số điện thoại đã đăng ký hoặc địa chỉ email dự phòng. Hệ thống sẽ đặt lại thông tin đăng nhập hoặc đăng ký thiết bị mới.
Bộ phận hỗ trợ: Cách thức được hỗ trợ thường là gọi điện thoại đến bộ phận hỗ trợ CNTT. Cách này thường được sử dụng khi nhân viên làm mất thiết bị hoặc trình xác thực mà SSPR dựa vào. Nhân viên hỗ trợ sẽ hỏi một loạt câu hỏi xác minh ngắn, thường lấy từ hồ sơ nhân sự, sau đó thực hiện thiết lập lại thủ công. Đối với các tài khoản có quyền truy cập đặc quyền, có thể có bước phê duyệt. Tuy nhiên, thường thì không có. Dữ liệu này có thể bị đánh cắp hoặc đã bị lộ trong một vụ vi phạm dữ liệu, hoặc được trích xuất từ mục tiêu trước đó. Đó chính là lỗ hổng được chứng minh là cực kỳ nguy hiểm.
Cuối cùng, cả hai phương án này đều không xác minh danh tính của cá nhân. Cả hai đều chỉ xác minh dữ liệu liên quan đến cá nhân đó. Sự phân biệt này rất quan trọng, bởi vì những trường hợp mà SSPR không thể xử lý lại chính là những trường hợp có mức độ rủi ro cao nhất và các biện pháp kiểm tra lỏng lẻo nhất.
Việc khôi phục hệ thống hỗ trợ kỹ thuật hiện đã được chứng minh là một con đường dẫn đến vi phạm an ninh
Đây không phải là lý thuyết suông. Chúng ta biết rằng kỹ thuật xã hội có thể vượt qua các biện pháp kiểm soát danh tính được tăng cường bằng cách nhắm vào các quy trình hỗ trợ và khôi phục, và rằng việc khôi phục qua bộ phận hỗ trợ kỹ thuật là phương thức xâm nhập đã được ghi nhận trong một số vụ xâm nhập gây thiệt hại nghiêm trọng nhất trong hai năm qua.
Trên thực tế, Gartner mô tả việc khôi phục tài khoản do quên mật khẩu hoặc mất thông tin đăng nhập là “phần rủi ro nhất trong chu kỳ quản lý danh tính.”
Scattered Spider đã sử dụng nó tại MGM, và một lần nữa trong các cuộc tấn công năm 2025 nhằm vào M&S, Co-op và Qantas. Tại MGM, chỉ cần một cuộc gọi điện thoại kéo dài mười phút là đủ để vượt qua hệ thống bảo mật trị giá hàng triệu đô la. Sau các vụ việc tại các cửa hàng bán lẻ ở Anh, NCSC đã đặc biệt khuyến cáo các tổ chức rà soát quy trình đặt lại mật khẩu tại bộ phận hỗ trợ, bao gồm cả cách xác thực nhân viên trước khi đặt lại mật khẩu, đặc biệt là đối với các tài khoản có quyền hạn cao hơn.
Quy mô vụ việc đã được ghi nhận. Một đơn kiện của Bộ Tư pháp Hoa Kỳ được công bố vào tháng 9 năm 2025 cáo buộc có ít nhất 120 vụ xâm nhập mạng liên quan đến 47 tổ chức của Hoa Kỳ, với các nạn nhân phải trả ít nhất 115 triệu đô la tiền chuộc. Các công tố viên mô tả một phương thức thực hiện nhất quán trong hầu hết các vụ việc: gọi đến bộ phận hỗ trợ kỹ thuật, yêu cầu đặt lại mật khẩu, chiếm quyền kiểm soát tài khoản quản trị, sau đó sử dụng quyền truy cập đó để đánh cắp dữ liệu.
Vấn đề không phải là các nhân viên thiếu cẩn trọng; mà là quy trình này yêu cầu họ phải đưa ra một quyết định quan trọng liên quan đến danh tính dựa trên những tín hiệu mà kẻ tấn công có thể dễ dàng tạo ra trên quy mô lớn. Việc khôi phục tài khoản không nên phụ thuộc vào việc ai đó quyết định xem một yêu cầu có hợp lệ hay không; mà phải yêu cầu bằng chứng về sự hiện diện thực sự.
Những tiến bộ trong lĩnh vực văn bản do trí tuệ nhân tạo (AI) tạo ra và nhân bản giọng nói khiến các cuộc gọi lừa đảo trở nên dễ thực hiện hơn. Một kẻ tấn công gọi đến bộ phận hỗ trợ kỹ thuật và tự xưng là nhân viên bị khóa tài khoản giờ đây có thể nói giọng giống hệt nhân viên đó, khiến nhân viên hỗ trợ mất đi một trong số ít các biện pháp kiểm tra bản năng mà họ thường thực hiện. Tuy nhiên, cuộc tấn công này không phụ thuộc vào yếu tố đó. Một kẻ tấn công có sự chuẩn bị kỹ lưỡng có thể tận dụng dữ liệu bị rò rỉ, thông tin trên LinkedIn, thuật ngữ nội bộ và một câu chuyện thuyết phục. Dưới áp lực, nhân viên hỗ trợ sẽ được yêu cầu “chỉ cần thiết lập lại xác thực hai yếu tố (MFA)” hoặc “giúp tôi truy cập lại tài khoản của mình.”
FBI và CISA đã ghi nhận bước quan trọng nhất. Những kẻ tấn công không chỉ làm thiết lập lại mật khẩu. Chúng còn làm thiết lập lại mã xác thực đa yếu tố (MFA), sau đó đăng ký các thiết bị xác thực của riêng mình. Việc thiết lập lại này không chỉ cho phép chúng truy cập tạm thời, mà còn biến chúng thành người dùng đáng tin cậy.
Tại sao các biện pháp kiểm soát khôi phục hệ thống cũ lại thất bại?
Hầu hết các dòng vốn phục hồi đều dựa vào hai loại yếu tố yếu.
- Các yếu tố kiến thức, chẳng hạn như các câu hỏi bảo mật, mã số nhân viên, tên người quản lý hoặc ngày sinh, chỉ thực sự bí mật đến mức độ của vụ vi phạm an ninh gần đây nhất hoặc kết quả tìm kiếm trên LinkedIn. Chúng chỉ chứng minh sự hiểu biết về một điều gì đó, chứ không phải danh tính đã được xác minh.
- Các yếu tố xác thực dựa trên thiết bị, chẳng hạn như mã xác thực một lần qua tin nhắn SMS, ứng dụng xác thực hoặc thiết bị dự phòng, đều có thể bị chia sẻ, bị lừa đảo và thường không sẵn có vào đúng thời điểm cần khôi phục. Nếu người dùng đã mất thiết bị, biện pháp kiểm soát gắn liền với thiết bị không thể là cách duy nhất để truy cập lại. Mã xác thực một lần (OTP) vẫn có thể hỗ trợ quá trình khôi phục, nhưng không nên được coi là bằng chứng xác thực danh tính.
Mã truy cập và các phương thức xác thực sinh trắc học tích hợp sẵn trên thiết bị an toàn hơn mật khẩu, nhưng chúng không giải quyết được mọi trường hợp ngoại lệ trong suốt vòng đời sử dụng. Passkeys vẫn cần quy trình khôi phục và đăng ký lại khi thay đổi thiết bị. Face ID và các phương thức xác thực sinh trắc học cục bộ tương tự cho phép người dùng truy cập vào thiết bị; tuy nhiên, bản thân chúng không thể tự chứng minh lại với tổ chức rằng chủ tài khoản chính là người dùng thực sự đang yêu cầu khôi phục.
Giải pháp: Xác minh lại người dùng, chứ không phải chứng chỉ
Việc xác thực sau khi khôi phục phải được thực hiện theo tiêu chuẩn ít nhất là ngang bằng với quy trình đăng nhập mà nó thay thế. Thay vì tự hỏi: “Liệu người này có đủ kiến thức để nghe có vẻ hợp lệ không?”, tổ chức nên tự hỏi: “Liệu người đúng, người thật có đang hiện diện tại đây vào lúc này không?”
Điều đó đòi hỏi phải có cơ chế phương pháp phát hiện sự hiện diện, nhằm xác nhận rằng khuôn mặt được hiển thị trong quá trình kiểm tra thuộc về một người thật đang có mặt tại chỗ vào thời điểm đó, chứ không phải là ảnh, đoạn ghi hình hoặc hình ảnh tổng hợp.
Không phải giải pháp nào cũng giống nhau, và sự khác biệt này chỉ thực sự quan trọng khi tiến hành đánh giá chứ không phải ở đây. Một số hệ thống chỉ được thử nghiệm chống lại các cuộc tấn công được ghi lại qua camera. Số lượng hệ thống được thử nghiệm chống lại các cuộc tấn công được đưa trực tiếp vào phần mềm, bỏ qua hoàn toàn camera, thì ít hơn. Nếu bạn đã đến giai đoạn so sánh các nhà cung cấp, đó chính là câu hỏi cần đặt ra: hệ thống này đã được đã được thử nghiệm độc lập , và do ai thực hiện?
Trong quá trình khôi phục, quy trình sẽ thay đổi như sau: Người dùng xác nhận thông tin liên hệ, quét giấy tờ tùy thân nếu được yêu cầu, thực hiện quét khuôn mặt có xác thực sự hiện diện, và chỉ sau đó mới có thể đặt lại thông tin đăng nhập hoặc kết nối lại thiết bị.
Và bởi vì việc xác minh này tạo ra một bản ghi về một người đã được xác thực chứ không phải là câu trả lời đúng cho một câu hỏi, nên việc đặt lại hệ thống sẽ để lại bằng chứng mà quy trình cũ chưa bao giờ tạo ra.
Tính năng khôi phục sinh trắc học dựa trên đám mây có thể hoạt động trên cả thiết bị mới lẫn thiết bị cũ, do đó điện thoại bị mất sẽ không trở thành “điểm lỗi duy nhất”. Tính năng này cũng giúp bộ phận hỗ trợ kỹ thuật tránh phải đưa ra quyết định rủi ro nhất, giảm số lượng yêu cầu đặt lại thiết bị và cung cấp cho các đội ngũ bảo mật một bản ghi kiểm toán rõ ràng hơn kể từ thời điểm liên kết lại.
Một quy trình thu hồi tài khoản hiệu quả cần chứng minh được điều gì?
Các nhà lãnh đạo an ninh không cần thêm một giải pháp dự phòng có mức độ đảm bảo thấp nữa. Họ cần một kế hoạch khôi phục có thể giải đáp những câu hỏi sau:
- Điều đó có phải là xác minh lại danh tính của người đó, hay chỉ là kiểm tra lại giấy tờ tùy thân?
- Nó có hoạt động được không khi thiết bị ban đầu của người dùng đã bị mất?
- Hệ thống có lưu lại thông tin về những người đã được xác minh hay không, chứ không chỉ ghi nhận việc quy trình đã được tuân thủ?
- Khả năng mô phỏng môi trường thực tế của nó đã được kiểm tra độc lập chưa, và được so sánh với tiêu chuẩn nào?
- Liệu nó có theo kịp các mối đe dọa đang nổi lên, các thủ đoạn thao túng tâm lý mới và các chiến thuật mạo danh hay không?
Nếu câu trả lời là “không”, thì quá trình khôi phục có thể dễ bị tấn công hơn so với quá trình đăng nhập mà nó được thiết kế để bảo vệ.
Việc khôi phục tài khoản không còn là một rắc rối chỉ xảy ra ở bộ phận hậu cần. Đây chính là điểm yếu của các hệ thống xác thực danh tính chặt chẽ nếu người dùng không được xác minh lại. Các tổ chức đi trước trong lĩnh vực này đang chuyển từ cách tiếp cận “bạn biết gì?” và “bạn có gì?” sang “bạn có thể chứng minh rằng mình chính là người đúng và thực sự sở hữu tài khoản đó không?”
Xem toàn bộ buổi hội thảo
Bài viết này dựa trên buổi hội thảo về deepfake tại nơi làm việc, bao gồm các phần trình diễn trực tiếp và bối cảnh rộng hơn về vòng đời nhận dạng, từ tuyển dụng từ xa đến các cuộc họp và các hành động có rủi ro cao của lực lượng lao động.
Xem Những điều kỳ lạ tại nơi làm việc: Bảo vệ tổ chức của bạn khỏi thế giới "Upside Down" của deepfake, sau đó tìm hiểu cách Bộ giải pháp iProov Workforce Solution Suite bảo vệ quá trình khôi phục tài khoản và liên kết lại thiết bị – những thời điểm mà các biện pháp kiểm soát dựa trên thông tin đăng nhập yếu nhất.
