Gần 370.000 bản ghi dữ liệu liên quan đến khách hàng Ngân hàng Nhà nước Ấn Độ (SBI) bị tin tặc tuyên bố rao bán trên diễn đàn ngầm. Phân tích dữ liệu được công bố cho thấy thông tin có thể đã bị thu thập hàng loạt thông qua các API phục vụ hoạt động ngân hàng, thay vì đánh cắp toàn bộ cơ sở dữ liệu trung tâm.
Ngày 18/10/2026, thông tin về vụ rò rỉ dữ liệu khách hàng của State Bank of India (SBI), ngân hàng lớn của Ấn Độ, được lan truyền trên các diễn đàn và mạng xã hội. Theo báo cáo phân tích do một nguồn tình báo an ninh mạng công bố, gói dữ liệu được quảng cáo có khoảng 375.000 dòng dữ liệu và 2.722 tệp PDF liên quan đến hoạt động ngân hàng.
Kết quả kiểm tra được nguồn này công bố ghi nhận 369.747 dòng dữ liệu và 2.722 tệp PDF. Dữ liệu được cho là liên quan đến khoảng 112.000 số điện thoại duy nhất, gần 88.000 tài khoản hoặc mã định danh khách hàng (CIF), cùng thông tin thuộc nhiều nghiệp vụ ngân hàng. Đây là số liệu từ phân tích gói dữ liệu được cho là bị rò rỉ, chưa phải số liệu xác nhận chính thức từ SBI.
Ngày 18/10/2026, thông tin về vụ rò rỉ dữ liệu khách hàng của State Bank of India (SBI), ngân hàng lớn của Ấn Độ, được lan truyền trên các diễn đàn và mạng xã hội. Theo báo cáo phân tích do một nguồn tình báo an ninh mạng công bố, gói dữ liệu được quảng cáo có khoảng 375.000 dòng dữ liệu và 2.722 tệp PDF liên quan đến hoạt động ngân hàng.
Kết quả kiểm tra được nguồn này công bố ghi nhận 369.747 dòng dữ liệu và 2.722 tệp PDF. Dữ liệu được cho là liên quan đến khoảng 112.000 số điện thoại duy nhất, gần 88.000 tài khoản hoặc mã định danh khách hàng (CIF), cùng thông tin thuộc nhiều nghiệp vụ ngân hàng. Đây là số liệu từ phân tích gói dữ liệu được cho là bị rò rỉ, chưa phải số liệu xác nhận chính thức từ SBI.
Dữ liệu có thể bị thu thập qua API, không phải đánh cắp toàn bộ cơ sở dữ liệu
Điểm đáng chú ý trong vụ việc nằm ở phương thức thu thập dữ liệu được mô tả trong báo cáo. Thay vì sao chép trực tiếp toàn bộ cơ sở dữ liệu nội bộ, đối tượng bị nghi ngờ đã sử dụng công cụ tự động gửi yêu cầu đến nhiều giao diện lập trình ứng dụng (API) của ngân hàng để lấy thông tin theo từng bản ghi.
Các API được nhận diện liên quan đến nhiều nghiệp vụ, bao gồm thông tin khách hàng đăng ký vay mua nhà, khoản vay bổ sung, hồ sơ mở tài khoản trực tuyến, kiểm tra thông tin đăng nhập và quy trình xác minh lại danh tính khách hàng (Re-KYC).
Các API được nhận diện liên quan đến nhiều nghiệp vụ, bao gồm thông tin khách hàng đăng ký vay mua nhà, khoản vay bổ sung, hồ sơ mở tài khoản trực tuyến, kiểm tra thông tin đăng nhập và quy trình xác minh lại danh tính khách hàng (Re-KYC).
Theo phân tích được công bố, dữ liệu thu thập bao gồm thông tin về hồ sơ vay, tài khoản, quy trình mở tài khoản và các tài liệu PDF liên quan. Công cụ thu thập được cho là lưu dữ liệu vào cơ sở dữ liệu SQLite riêng, đồng thời ghi lại thời gian chạy, số yêu cầu thành công hoặc thất bại và lịch sử thu thập.
Những dấu vết này cho thấy hoạt động có thể đã được tự động hóa và triển khai theo từng đợt. Tuy nhiên, việc một công cụ lưu dữ liệu trong SQLite không tự nó chứng minh dữ liệu đã bị đánh cắp từ hệ thống ngân hàng; đây chỉ là cấu trúc lưu trữ phía người thu thập được mô tả trong báo cáo.
Hoạt động thu thập kéo dài khoảng sáu ngày
Theo dòng thời gian do nguồn phân tích công bố, hoạt động thu thập dữ liệu bắt đầu từ ngày 9/10/2026, với các bản ghi đầu tiên thuộc quy trình xử lý thông tin chấp thuận của khách hàng. Trong những ngày tiếp theo, công cụ được cho là tiếp tục thu thập dữ liệu về hồ sơ mở tài khoản, xác minh danh tính, hồ sơ vay và tài liệu ngân hàng.
Đến ngày 13/10, hoạt động thu thập tài liệu PDF được ghi nhận. Ngày 15/10, các tệp PDF được cho là đã được đóng gói thành một tệp nén dung lượng khoảng 3,83 GB. Cùng ngày, các hoạt động thu thập cuối cùng được ghi nhận trong nhật ký. Đến ngày 16/10, một nền tảng giám sát mối đe dọa được cho là đã phát hiện bài đăng liên quan trên BreachForums.
Chuỗi thời gian này phù hợp với giả thuyết dữ liệu được thu thập từng phần, sau đó tổng hợp và đưa lên diễn đàn. Tuy nhiên, cần phân biệt thời điểm xuất hiện trong nhật ký, thời điểm dữ liệu được đóng gói và thời điểm thông tin được công khai; các mốc này không tự chứng minh danh tính hay động cơ của đối tượng thực hiện.
Đến ngày 13/10, hoạt động thu thập tài liệu PDF được ghi nhận. Ngày 15/10, các tệp PDF được cho là đã được đóng gói thành một tệp nén dung lượng khoảng 3,83 GB. Cùng ngày, các hoạt động thu thập cuối cùng được ghi nhận trong nhật ký. Đến ngày 16/10, một nền tảng giám sát mối đe dọa được cho là đã phát hiện bài đăng liên quan trên BreachForums.
Chuỗi thời gian này phù hợp với giả thuyết dữ liệu được thu thập từng phần, sau đó tổng hợp và đưa lên diễn đàn. Tuy nhiên, cần phân biệt thời điểm xuất hiện trong nhật ký, thời điểm dữ liệu được đóng gói và thời điểm thông tin được công khai; các mốc này không tự chứng minh danh tính hay động cơ của đối tượng thực hiện.
Lỗ hổng kiểm soát truy cập có thể gây hậu quả trên diện rộng
Nếu các nhận định trong báo cáo được xác minh, vụ việc cho thấy nguy cơ nghiêm trọng từ việc kiểm soát quyền truy cập API không chặt chẽ.
API cho phép các ứng dụng trao đổi dữ liệu với hệ thống ngân hàng và thực hiện những nghiệp vụ cụ thể. Nhưng nếu hệ thống chỉ kiểm tra yêu cầu có đúng định dạng mà không xác minh đầy đủ người dùng có quyền truy cập bản ghi được yêu cầu hay không, đối tượng có thể lợi dụng API để truy xuất dữ liệu của những khách hàng khác.
Đây là dạng lỗ hổng thường được gọi là kiểm soát truy cập đối tượng bị lỗi (Broken Object Level Authorization – BOLA). Trong một số trường hợp, đối tượng chỉ cần thay đổi mã định danh trong yêu cầu để truy cập bản ghi không thuộc quyền của mình. Nếu API còn cho phép truy vấn hàng loạt và không có giới hạn phù hợp, lượng dữ liệu bị lộ có thể tăng nhanh mà không cần xâm nhập trực tiếp vào máy chủ cơ sở dữ liệu.
Việc luân phiên địa chỉ mạng thông qua proxy và gửi yêu cầu theo từng đợt cũng có thể khiến hoạt động thu thập khó bị phát hiện hơn nếu hệ thống giám sát chỉ dựa vào số lượng yêu cầu từ một địa chỉ IP. Tuy nhiên, nhật ký có lỗi kết nối proxy không đủ để kết luận rằng đối tượng đã thành công trong việc né tránh cơ chế phát hiện của ngân hàng.
API cho phép các ứng dụng trao đổi dữ liệu với hệ thống ngân hàng và thực hiện những nghiệp vụ cụ thể. Nhưng nếu hệ thống chỉ kiểm tra yêu cầu có đúng định dạng mà không xác minh đầy đủ người dùng có quyền truy cập bản ghi được yêu cầu hay không, đối tượng có thể lợi dụng API để truy xuất dữ liệu của những khách hàng khác.
Đây là dạng lỗ hổng thường được gọi là kiểm soát truy cập đối tượng bị lỗi (Broken Object Level Authorization – BOLA). Trong một số trường hợp, đối tượng chỉ cần thay đổi mã định danh trong yêu cầu để truy cập bản ghi không thuộc quyền của mình. Nếu API còn cho phép truy vấn hàng loạt và không có giới hạn phù hợp, lượng dữ liệu bị lộ có thể tăng nhanh mà không cần xâm nhập trực tiếp vào máy chủ cơ sở dữ liệu.
Việc luân phiên địa chỉ mạng thông qua proxy và gửi yêu cầu theo từng đợt cũng có thể khiến hoạt động thu thập khó bị phát hiện hơn nếu hệ thống giám sát chỉ dựa vào số lượng yêu cầu từ một địa chỉ IP. Tuy nhiên, nhật ký có lỗi kết nối proxy không đủ để kết luận rằng đối tượng đã thành công trong việc né tránh cơ chế phát hiện của ngân hàng.
Nguy cơ đối với khách hàng và tổ chức tài chính
Dữ liệu ngân hàng bị lộ có thể tạo điều kiện cho các chiến dịch lừa đảo nhắm mục tiêu. Khi có thông tin liên quan đến hồ sơ vay, tài khoản hoặc quy trình mở tài khoản, kẻ gian có thể sử dụng những chi tiết này để giả danh ngân hàng, nhân viên tín dụng hoặc bộ phận xác minh danh tính, khiến cuộc gọi và tin nhắn lừa đảo trở nên đáng tin hơn.
Trong trường hợp dữ liệu bị lộ bao gồm thông tin nhận dạng và tài liệu hồ sơ, nguy cơ còn có thể mở rộng sang hành vi giả mạo danh tính hoặc lợi dụng thông tin cá nhân để thực hiện các thủ tục trái phép. Mức độ nguy hiểm thực tế phụ thuộc vào những trường dữ liệu cụ thể bị lộ và khả năng đối tượng kết hợp chúng với nguồn thông tin khác. Đối với SBI, sự cố nếu được xác nhận có thể gây ảnh hưởng đến niềm tin khách hàng, kéo theo chi phí điều tra, khắc phục và nghĩa vụ tuân thủ quy định bảo vệ dữ liệu có liên quan.
Để giảm thiểu rủi ro, các tổ chức tài chính cần kiểm tra quyền truy cập ở cấp độ từng bản ghi, giới hạn số lượng dữ liệu được truy xuất, giám sát hành vi truy vấn bất thường và rà soát các API liên quan đến thông tin nhạy cảm. Cơ chế xác thực người dùng cần đi kèm việc kiểm tra quyền thực hiện từng thao tác, thay vì chỉ xác nhận người gửi yêu cầu đã đăng nhập thành công.
Khách hàng cũng nên cảnh giác với các cuộc gọi, tin nhắn yêu cầu cung cấp OTP, mật khẩu hoặc thông tin ngân hàng với lý do xác minh hồ sơ vay hay xử lý sự cố. Khi nhận được yêu cầu bất thường, người dùng nên chủ động liên hệ ngân hàng qua kênh chính thức.
Vụ việc SBI cho thấy một nguy cơ đáng lưu ý trong bảo mật ngân hàng số: hệ thống không nhất thiết phải bị chiếm quyền quản trị hoặc toàn bộ cơ sở dữ liệu bị sao chép mới dẫn đến rò rỉ thông tin quy mô lớn. Chỉ một API thiếu cơ chế kiểm soát truy cập phù hợp cũng có thể trở thành điểm khởi đầu cho hoạt động thu thập dữ liệu hàng loạt.
Trong trường hợp dữ liệu bị lộ bao gồm thông tin nhận dạng và tài liệu hồ sơ, nguy cơ còn có thể mở rộng sang hành vi giả mạo danh tính hoặc lợi dụng thông tin cá nhân để thực hiện các thủ tục trái phép. Mức độ nguy hiểm thực tế phụ thuộc vào những trường dữ liệu cụ thể bị lộ và khả năng đối tượng kết hợp chúng với nguồn thông tin khác. Đối với SBI, sự cố nếu được xác nhận có thể gây ảnh hưởng đến niềm tin khách hàng, kéo theo chi phí điều tra, khắc phục và nghĩa vụ tuân thủ quy định bảo vệ dữ liệu có liên quan.
Để giảm thiểu rủi ro, các tổ chức tài chính cần kiểm tra quyền truy cập ở cấp độ từng bản ghi, giới hạn số lượng dữ liệu được truy xuất, giám sát hành vi truy vấn bất thường và rà soát các API liên quan đến thông tin nhạy cảm. Cơ chế xác thực người dùng cần đi kèm việc kiểm tra quyền thực hiện từng thao tác, thay vì chỉ xác nhận người gửi yêu cầu đã đăng nhập thành công.
Khách hàng cũng nên cảnh giác với các cuộc gọi, tin nhắn yêu cầu cung cấp OTP, mật khẩu hoặc thông tin ngân hàng với lý do xác minh hồ sơ vay hay xử lý sự cố. Khi nhận được yêu cầu bất thường, người dùng nên chủ động liên hệ ngân hàng qua kênh chính thức.
Vụ việc SBI cho thấy một nguy cơ đáng lưu ý trong bảo mật ngân hàng số: hệ thống không nhất thiết phải bị chiếm quyền quản trị hoặc toàn bộ cơ sở dữ liệu bị sao chép mới dẫn đến rò rỉ thông tin quy mô lớn. Chỉ một API thiếu cơ chế kiểm soát truy cập phù hợp cũng có thể trở thành điểm khởi đầu cho hoạt động thu thập dữ liệu hàng loạt.
