🎉 Giảm 20% cho đơn hàng đầu tiên!✦🚚 Miễn phí vận chuyển cho đơn trên 500.000₫✦⚡ Flash Sale — Số lượng có hạn!✦🎁 Quà tặng kèm cho đơn từ 1.000.000₫✦🎉 Giảm 20% cho đơn hàng đầu tiên!✦🚚 Miễn phí vận chuyển cho đơn trên 500.000₫✦⚡ Flash Sale — Số lượng có hạn!✦🎁 Quà tặng kèm cho đơn từ 1.000.000₫✦
Hacker không cần vượt Firewall: khi kẻ tấn công đăng nhập bằng tài khoản của chính nhân viên
Quay lại Blog

Hacker không cần vượt Firewall: khi kẻ tấn công đăng nhập bằng tài khoản của chính nhân viên

8 tháng 11, 202614 phút đọcVũ Khôi
Tin tức
#Wotech
Vũ Khôi

Vũ Khôi

Tác giả tại Wotech Electronics Blog

Hacker không cần vượt Firewall: khi kẻ tấn công đăng nhập bằng tài khoản của chính nhân viên

Trả lời nhanh

  • Hacker hiện đại thường không phá Firewall — trong nhiều vụ xâm nhập, kẻ tấn công đăng nhập thẳng vào mạng nội bộ bằng một tài khoản hợp lệ bị chiếm: tài khoản VPN, Microsoft 365 hay tài khoản quản trị.
  • Firewall kiểm soát lưu lượng theo chính sách, không xác minh được con người đứng sau một kết nối đã được cho phép có phải nhân viên thật hay không.
  • Một tài khoản bị chiếm là điểm khởi đầu, chưa phải điểm kết thúc: từ một phiên đăng nhập bị đánh cắp qua phishing, kẻ tấn công có thể leo thang đặc quyền và di chuyển ngang trong mạng nếu quyền truy cập quá rộng và mạng nội bộ thiếu phân đoạn.
  • 5 việc doanh nghiệp cần rà soát ngay: kiểm soát tài khoản đặc quyền; dùng MFA chống phishing (FIDO2/Passkey); phân đoạn mạng thực chất; quản lý Service Account; giám sát hành vi sau khi đăng nhập.
  • Nguyên tắc cốt lõi là Defense in Depth và Zero Trust: thiết kế hệ thống sao cho một sai sót đơn lẻ — một nhân viên bấm nhầm link, một tài khoản bị lộ — không thể kéo sập toàn bộ hạ tầng.

Bảo mật định danh là gì?

Bảo mật định danh (Identity Security) là tập hợp các biện pháp bảo vệ tài khoản, mật khẩu, phiên đăng nhập và quyền truy cập của người dùng, ứng dụng và dịch vụ trong hệ thống CNTT. Khi hạ tầng ngày càng mở — làm việc từ xa qua VPN, email và ứng dụng chuyển lên đám mây như Microsoft 365 — danh tính trở thành "chu vi bảo mật mới": ai chứng minh được mình là một tài khoản hợp lệ sẽ được hệ thống cho qua, bất kể người đó ngồi ở đâu.

Vì sao hacker không cần vượt qua Firewall?

Hãy hình dung một doanh nghiệp đầu tư bài bản cho biên mạng: Firewall thế hệ mới, đầy đủ bản quyền, bật IPS, Antivirus, Web Filtering và Application Control. Bảng điều khiển xanh, mỗi ngày hệ thống chặn hàng nghìn lượt truy cập đáng ngờ, ban lãnh đạo yên tâm, đội IT cũng yên tâm.

Rồi một ngày, kẻ tấn công xuất hiện ngay bên trong mạng nội bộ. Không có cảnh báo tấn công từ Internet, không ai "phá" Firewall, không có đợt DDoS nào. Chỉ có một tài khoản VPN đăng nhập thành công lúc 2 giờ sáng — username hợp lệ, mật khẩu chính xác, MFA cũng đã được xác nhận. Hệ thống mở cửa, vì với Firewall, đó là một kết nối được phép.

Câu chuyện minh họa này cho thấy một giả định từng rất phổ biến trong thiết kế mạng truyền thống: bên ngoài là không tin cậy, bên trong là an toàn. Giả định đó không còn đứng vững. Khi một tài khoản VPN bị chiếm quyền, hoặc một máy tính nội bộ nhiễm mã độc, kẻ tấn công bắt đầu hoạt động từ chính vị trí mà hệ thống đã cho phép truy cập. Nó không cần tìm cách vượt Firewall từ bên ngoài — nó đi qua những kết nối mà Firewall vốn được cấu hình để cho phép.

Firewall có bảo vệ được doanh nghiệp trước tài khoản bị chiếm không?

Câu trả lời là: chỉ một phần. Firewall vẫn là lớp bảo vệ cần thiết ở biên mạng — lọc lưu lượng, chặn các kết nối trái phép, ghi log. Nhưng cần hiểu đúng giới hạn của nó:

Firewall kiểm soát lưu lượng theo chính sách. Nó không thể tự bảo đảm rằng mọi hành động đi qua một kết nối được phép đều là hành động của người dùng hợp pháp.

Nói cách khác, Firewall giống người gác cổng kiểm tra giấy tờ: giấy tờ hợp lệ thì cho qua. Nếu kẻ tấn công cầm đúng "giấy tờ" — tài khoản và phiên đăng nhập thật của nhân viên — người gác cổng không có cơ sở để từ chối. Phần việc còn lại thuộc về các lớp kiểm soát phía sau cổng: quản lý định danh, phân quyền, phân đoạn mạng và giám sát hành vi.

Một tài khoản nhân viên bị chiếm có thể nguy hiểm đến mức nào?

Xét một doanh nghiệp khoảng 500 nhân viên, khá điển hình: Active Directory quản lý toàn bộ tài khoản, nhân viên làm việc từ xa qua VPN, các phòng ban dùng chung File Server, phần mềm ERP kết nối cơ sở dữ liệu, máy chủ ứng dụng nằm trong các VLAN riêng.

Một ngày, nhân viên kế toán nhận được email giả mạo yêu cầu "xác nhận lại tài khoản Microsoft 365". Nhân viên bấm vào liên kết, đăng nhập, xác nhận MFA — nhưng trang đăng nhập đó là giả, thuộc một cuộc tấn công phishing có khả năng đánh cắp phiên xác thực (session). Kẻ tấn công chiếm được một phiên đăng nhập hợp lệ mà không cần biết mật khẩu thật sự bị lộ ở đâu.

Cần nói rõ một điểm kỹ thuật quan trọng: chiếm được tài khoản Microsoft 365 không có nghĩa là mặc nhiên đăng nhập được VPN hay Active Directory nội bộ. Điều đó còn phụ thuộc vào kiến trúc định danh, cơ chế đồng bộ tài khoản, đăng nhập một lần (SSO), quyền truy cập và các lớp bảo vệ đang triển khai. Nhưng nếu trong hệ thống tồn tại những điểm liên thông yếu — mật khẩu dùng chung giữa các hệ thống, quyền truy cập quá rộng, tài khoản đặc quyền thiếu kiểm soát — thì một tài khoản bị chiếm sẽ là bàn đạp để mở rộng xâm nhập. Một tài khoản bị chiếm quyền có thể là điểm khởi đầu, chứ không nhất thiết là điểm kết thúc của cuộc tấn công.

Domain Admin và Service Account rủi ro ra sao?

Nếu tài khoản nhân viên là "chìa khóa thường", thì trong hệ thống Windows/Active Directory còn hai loại "chìa khóa" nguy hiểm hơn nhiều:

Domain Admin — chiếc chìa khóa vạn năng. Trong nhiều môi trường, kỹ thuật viên từng dùng tài khoản Domain Admin cho mọi việc: cài phần mềm, join domain, remote máy trạm, cấu hình máy chủ, thậm chí đăng nhập vào máy người dùng chỉ để sửa một chiếc máy in. Tiện thật — một tài khoản làm được gần như mọi việc. Nhưng nếu thông tin xác thực đặc quyền này bị lộ, hậu quả có thể ở quy mô toàn doanh nghiệp: thay đổi Group Policy, tạo tài khoản đặc quyền mới, tác động đến các máy tính trong domain hoặc phá hoại dịch vụ quan trọng. Một tài khoản quản trị dùng sai cách có thể biến sự cố của một máy trạm thành khủng hoảng của cả hệ thống.

Service Account — những chiếc chìa khóa phụ bị lãng quên. Đó là các tài khoản chạy dịch vụ SQL, phục vụ ứng dụng ERP, thực hiện tác vụ tự động hoặc tích hợp giữa các hệ thống. Không ít Service Account được tạo từ nhiều năm trước: mật khẩu gần như không bao giờ thay đổi, không có người phụ trách rõ ràng, được cấp quyền cao hơn nhu cầu thực tế, thậm chí một tài khoản dùng chung cho nhiều dịch vụ. Đến khi rà soát, không ai dám đổi mật khẩu — vì không biết đổi xong thì ứng dụng nào sẽ "chết". Quản lý định danh vì thế không chỉ là chuyện tài khoản nhân viên: máy móc, ứng dụng và dịch vụ cũng có danh tính, quyền hạn và vòng đời cần được quản lý.

Loại tài khoản Rủi ro điển hình Cách kiểm soát nên áp dụng
Tài khoản nhân viên Bị phishing đánh cắp mật khẩu hoặc phiên đăng nhập MFA chống phishing, đào tạo nhận diện email giả, kiểm soát thiết bị và phiên đăng nhập
Tài khoản VPN Bị chiếm rồi dùng để vào thẳng mạng nội bộ, thường ngoài giờ MFA mạnh, giới hạn dải hệ thống được phép truy cập sau khi vào VPN, cảnh báo đăng nhập bất thường
Domain Admin Một lần lộ là mất quyền kiểm soát toàn domain Tách tài khoản quản trị khỏi tài khoản thường, PAM, Just-in-Time Access, nguyên tắc Least Privilege
Service Account Mật khẩu tĩnh nhiều năm, không chủ sở hữu, quyền quá cao Kiểm kê và gán chủ sở hữu, rà soát quyền, ưu tiên gMSA hoặc vault quản lý bí mật, loại bỏ tài khoản không dùng

Doanh nghiệp cần làm gì để ngăn kẻ tấn công đi xa sau khi đăng nhập?

Thay vì chỉ nghĩ đến việc mua thêm thiết bị bảo mật, doanh nghiệp nên bắt đầu bằng việc rà soát năm vấn đề sau:

Thứ nhất — kiểm soát tài khoản đặc quyền. Tách tài khoản quản trị khỏi tài khoản làm việc thông thường, hạn chế đăng nhập đặc quyền trên máy trạm không tin cậy, áp dụng quản lý truy cập đặc quyền (PAM), cấp quyền tạm thời theo nhu cầu (Just-in-Time Access) và nguyên tắc đặc quyền tối thiểu (Least Privilege) khi phù hợp.

Thứ hai — MFA phải đủ mạnh. MFA bằng SMS hoặc thông báo đẩy (push) thông thường vẫn có thể bị lợi dụng trong một số hình thức phishing, điển hình là tấn công đánh cắp phiên đăng nhập. Với các tài khoản quan trọng, nên ưu tiên phương thức chống phishing như khóa bảo mật FIDO2 hoặc Passkey, đồng thời kiểm soát phiên đăng nhập, thiết bị và các dấu hiệu xác thực bất thường.

Thứ ba — phân đoạn mạng thực chất. Chia VLAN chưa đồng nghĩa với phân đoạn mạng (Network Segmentation) an toàn: nếu các VLAN vẫn định tuyến qua lại với chính sách cho phép quá rộng, việc phân chia chỉ mang ý nghĩa tổ chức mạng. Cần kiểm soát rõ các luồng kết nối giữa vùng người dùng (User), máy chủ (Server), vùng quản trị (Management), vùng sao lưu (Backup) và các vùng nhạy cảm.

Thứ tư — quản lý Service Account. Kiểm kê toàn bộ tài khoản dịch vụ, xác định chủ sở hữu, rà soát quyền, loại bỏ tài khoản không còn sử dụng, ưu tiên gMSA hoặc cơ chế quản lý bí mật phù hợp thay vì để mật khẩu tĩnh tồn tại nhiều năm.

Thứ năm — giám sát hành vi sau đăng nhập. Một tài khoản đăng nhập thành công lúc 2 giờ sáng chưa đủ để kết luận bị tấn công. Nhưng nếu tài khoản đó đột nhiên truy cập hàng loạt máy chủ, thay đổi nhóm đặc quyền hoặc thực hiện những thao tác chưa từng xuất hiện trước đây, hệ thống cần phát hiện và cảnh báo. Bảo mật không nên kết thúc ở màn hình đăng nhập.

Zero Trust và Defense in Depth nghĩa là gì trong thực tế?

Bài học lớn nhất rút ra từ câu chuyện trên: bảo mật không thể chỉ dựa vào sự cẩn thận của từng nhân viên. Không thể yêu cầu hàng trăm con người tuyệt đối không bao giờ bấm nhầm một đường link, không thể kỳ vọng mọi kỹ thuật viên không bao giờ mắc lỗi, cũng không thể tin rằng mọi tài khoản sẽ an toàn mãi mãi.

Thay vào đó, hệ thống phải được thiết kế để một sai sót đơn lẻ không dễ dàng kéo theo sự sụp đổ của toàn bộ hạ tầng:

  • Một nhân viên bị phishing không nên đồng nghĩa với việc hacker kiểm soát được cả Domain.
  • Một máy tính nhiễm mã độc không nên mặc nhiên truy cập được hệ thống Backup.
  • Một tài khoản VPN bị chiếm không nên có quyền đi khắp mạng nội bộ.
  • Một tài khoản quản trị bị lộ không nên là dấu chấm hết cho mọi lớp bảo vệ.

Đó là ý nghĩa thực tế của Defense in Depth (phòng thủ nhiều lớp) và Zero Trust (không tin tưởng mặc định): không phải mua thật nhiều thiết bị, mà là xây dựng nhiều lớp kiểm soát độc lập, để khi một lớp thất bại, những lớp còn lại vẫn có cơ hội ngăn chặn hoặc giới hạn thiệt hại. Câu hỏi mà mỗi đội IT nên tự trả lời: nếu ngày mai hacker đăng nhập thành công bằng một tài khoản hợp lệ trong doanh nghiệp, hệ thống còn những lớp bảo vệ nào để ngăn hắn đi xa hơn? Nếu câu trả lời chỉ là "đã có Firewall rồi mà", thì đã đến lúc xem lại kiến trúc bảo mật — bởi đôi khi, hacker không cần phá cửa; nó chỉ cần một chiếc chìa khóa mà chính chúng ta đã vô tình để lộ. Và điều đáng sợ nhất không phải nó đã vào được, mà là sau khi vào, chẳng còn mấy cánh cửa buộc nó phải dừng lại.

Câu hỏi thường gặp

Có Firewall mạnh rồi, doanh nghiệp có cần quan tâm bảo mật tài khoản nữa không? Có. Firewall chặn các kết nối trái phép ở biên mạng, nhưng không phân biệt được người dùng thật với kẻ tấn công đang dùng một tài khoản hợp lệ bị chiếm. Bảo mật định danh là lớp bổ sung bắt buộc, không phải lựa chọn thêm.

MFA bằng SMS hoặc thông báo đẩy đã đủ an toàn chưa? Chưa hoàn toàn. Một số hình thức phishing hiện nay có thể đánh cắp cả phiên đăng nhập sau khi người dùng đã xác nhận MFA. Với tài khoản quan trọng, nên dùng phương thức chống phishing như khóa FIDO2 hoặc Passkey, kết hợp kiểm soát thiết bị và phiên đăng nhập.

Chia VLAN có phải là đã phân đoạn mạng an toàn chưa? Chưa chắc. Nếu giữa các VLAN vẫn cho phép kết nối rộng rãi, phân đoạn chỉ mang tính tổ chức. Phân đoạn thực chất phải đi kèm chính sách kiểm soát cụ thể từng luồng kết nối giữa các vùng User, Server, Management, Backup.

Service Account là gì và vì sao được coi là rủi ro bị lãng quên? Service Account là tài khoản dùng để chạy dịch vụ, ứng dụng hoặc tác vụ tự động. Chúng nguy hiểm vì thường có mật khẩu không đổi trong nhiều năm, không có chủ sở hữu rõ ràng và được cấp quyền cao hơn nhu cầu — một "chìa khóa phụ" mà kẻ tấn công rất muốn tìm thấy.

Làm sao phát hiện kẻ tấn công đang dùng một tài khoản hợp lệ? Dựa vào giám sát hành vi sau đăng nhập: đăng nhập ngoài giờ bất thường, truy cập hàng loạt hệ thống lạ, thay đổi nhóm đặc quyền, thao tác chưa từng xuất hiện trong lịch sử của tài khoản. Các dấu hiệu này cần được hệ thống giám sát ghi nhận và cảnh báo kịp thời.


Nguồn tham khảo: bài viết "Khi bảo mật không còn là chuyện của riêng IT — #03: Hacker không cần vượt Firewall, đôi khi nó đăng nhập bằng tài khoản của chính nhân viên" của tác giả Dũng Nguyễn, đăng trong nhóm Cộng đồng Digital SArch trên Facebook ngày 03/11/2026. Các tình huống trong bài gốc mang tính minh họa cho rủi ro quản lý định danh và quyền truy cập.