Tài khoản bị chiếm sau sự cố AWS

 (news.ycombinator.com)
1 điểm bởi GN⁺ 2025-10-22 | 1 bình luận | Chia sẻ qua WhatsApp

Sau sự cố gián đoạn dịch vụ gần đây tại AWS, một người dùng cho biết đã gặp trường hợp tài khoản AWS của mình bị kẻ tấn công bên ngoài chiếm đoạt.

Lộ trình xâm nhập và tình hình sự cố

  • Trong thời gian có sự cố, đã có nhắc đến việc một số chính sách bảo mật có thể không hoạt động bình thường
  • Kẻ tấn công đã để lại dấu vết truy cập bất thường trên nhật ký tài khoản sau sự cố, và xuất hiện hiện tượng một số tài nguyên bị tạo/xóa một cách bất ngờ
  • Người dùng bày tỏ lo ngại về khả năng thay đổi quyền hoặc lộ thông tin xác thực

Thiệt hại và xử lý

  • Chi phí tăng, rò rỉ dữ liệu và các thiệt hại thực tế khác đã xảy ra
  • Người dùng đã liên hệ với đội hỗ trợ AWS để hỏi về diễn biến vụ việc và cách ứng phó
  • Cộng đồng nhấn mạnh tầm quan trọng của biện pháp phòng ngừa như kích hoạt xác thực hai lớp, giảm thiểu quyền truy cập theo vai trò

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-10-22
Ý kiến Hacker News

  • Bình thường người ta thường nghĩ đây chỉ là trùng hợp, nhưng tôi cũng từng có trường hợp tài khoản khách hàng bị xâm nhập. Khách hàng là một tổ chức nhỏ, và hai tài khoản IAM cũ đã không dùng hơn 5 năm bỗng chốc xuất hiện lịch sử đăng nhập console và đổi mật khẩu. Theo điều tra thì đến nay chỉ phát hiện được việc kích hoạt truy cập AWS SES production và ticket hỗ trợ để nâng quota email hằng ngày lên 50.000. Một tài khoản đã im lặng hơn 5 năm mà bỗng hoạt động đúng lúc này thì khá đáng nghi.

    • Có mùi tấn công phishing. Ví dụ như nhận email mạo danh thông báo sự cố AWS, sau đó dụ người dùng đăng nhập console; nếu xác thực qua một wrapper có chủ đích xấu thì có thể làm lộ bảo mật tài khoản.
    • Tôi đã từng gặp gần như y hệt việc này cách đây một năm. Đăng nhập bằng một tài khoản rất cũ, truy cập SES rồi yêu cầu tăng email quota. Chúng tôi phản ứng nhanh được vì ticket tăng quota là bắt buộc. Nếu chưa được kiểm tra, cũng nên kiểm tra thêm các Role mới tạo. Chúng tôi đã ngay lập tức dọn dẹp tài khoản bị compromise, và khi rà soát tổng thể các Role thì tôi đã xóa hết các Role có tuổi đời dưới 1 tháng hoặc có quyền admin. Mặt khác, chúng tôi cũng xác nhận rằng cuộc xâm nhập thực sự bắt đầu từ chính key của chúng tôi. Thời điểm tạo user đầu tiên gần như trước yêu cầu SES thực tế gần một tháng, vì vậy có thể kẻ tấn công đã xâm nhập trước đó và chớp cơ hội khi AWS có lỗi. Việc này cũng bị hòa lẫn với các vấn đề AWS khác nên khó phát hiện.

  • Khi đã có quyền truy cập, người tấn công có thể chờ một sự kiện gây hỗn loạn như sự cố hạ tầng AWS rồi tại thời điểm đó tấn công để ẩn mình trong đám hỗn loạn. Dù token bị lộ vài tuần hay vài tháng trước, họ có thể chọn chiến thuật đợi đến khi có sự kiện lớn mới hành động. Nếu là mình thì cũng muốn thử cách này.

    • Đương nhiên là có thể. Trong vai trò làm due diligence, tôi cũng đã nghe trực tiếp các case kiểu này. Kẻ tấn công có thể chuẩn bị sẵn trước rồi chờ tới các mốc quan trọng như việc bán công ty mới kích hoạt. Những kẻ tấn công có mức độ cao hơn thường chớp cơ hội này và chuẩn bị trước.
    • Tôi cũng là thành viên nhóm, và thực tế đã từng nhận được email cảnh báo liên quan đến key bị lạm dụng hôm nay cách đây 2 năm từ một người lạ. Nhưng cho đến tối qua vẫn chưa có bất kỳ dấu hiệu lạm dụng nào.
    • Ngược lại, tôi nghĩ đây có thể là thời điểm không tốt cho attacker. Bây giờ ai cũng đang chú ý AWS và đăng nhập nhiều hơn, nên mọi bất thường đều dễ bị phát hiện hơn. Nếu công ty chúng ta dùng AWS thì trong tình huống như vậy sẽ càng để ý sát sao hơn nữa.

  • Nếu là attacker, khi chọn thời điểm tấn công thì một sự cố lớn mà hệ thống thu thập log cũng không vận hành tốt có thể là cơ hội tốt. Họ có thể đã lạm dụng đúng lúc đã bị compromise rồi, hoặc tận dụng hỏng AWS để tấn công thứ hai bằng tài nguyên của chính họ.

  • Nếu trong môi trường cloud xuất hiện một resource lạ (như EC2...), có thể kiểm tra trên CloudTrail xem nó sinh ra từ event nào, điển hình là event RunInstances.

    • Gần đây tôi không dùng AWS nên chưa thể kiểm tra trực tiếp trên console, nhưng nếu bạn đang gặp chuyện tương tự thì có thể tham khảo các bước tạm thời sau:
      1. Kiểm tra account/chủ thể tạo EC2 (eventSource:ec2.amazonaws.com, eventName:RunInstances)
      2. Theo dõi hành động tiếp theo dựa trên userIdentity
      3. Kiểm tra lịch sử đăng nhập console trực tiếp (eventSource:signin.amazonaws.com, userIdentity.type:[Root/IAMUser/AssumedRole/FederatedUser/AWSLambda], eventName:ConsoleLogin)
      4. Kiểm tra lịch sử yêu cầu xác thực qua Security Token Service (eventSource:sts.amazonaws.com, eventName:GetSessionToken)
      5. Kiểm tra việc dùng AssumeRole thông qua STS session (eventSource:sts.amazonaws.com, eventName:AssumeRole)
      6. Kiểm tra các nỗ lực duy trì persistence như tạo mới IAM Role/Account (eventSource:iam.amazonaws.com, eventName:CreateUser/ DeleteUser)
      7. Kiểm tra xem Role/Account cũ có bị nâng quyền cao hơn hay không (eventSource:iam.amazonaws.com, eventName:CreateRole/DeleteRole/AttachRolePolicy/DetachRolePolicy)
      8. Kiểm tra lịch sử tạo/xóa Access Key (eventSource:iam.amazonaws.com, eventName:CreateAccessKey/DeleteAccessKey)
      9. Kiểm tra khả năng backdoor qua thay đổi IAMInstanceProfile của production EC2 (tham khảo chi tiết trong ví dụ AWS Docs) Nếu nghi ngờ bị compromise sâu hơn, nên nhờ chuyên gia kiểm tra môi trường và tiến hành audit.
    • Thông tin này khá hữu ích nên tôi sẽ xem lại log thêm. Một vài điểm khác mình quan sát thêm:
      1. Dưới root account có khoảng hơn 20 org được tạo ra và đều dùng địa chỉ email cùng domain co.jp
      2. Kẻ tấn công đã tạo sẵn nhiều template fargate
      3. Tạo tài nguyên ở 16~17 region AWS
      4. Có request tăng quota tài nguyên không cần thiết như SES, WS Fargate, request bảo trì SageMaker Notebook... (mình nhận được nhiều email cảnh báo cho các request này)
      5. Phát hiện một số email thêm tên mới kiểu randomname@outlook.com
    • RunInstances event chính là event đó.

  • Có một số người dùng Reddit nói rằng trong lúc AWS sự cố, khi refresh thì họ thấy bị đăng nhập tạm thời bằng một user hoàn toàn khác.

    • Ở công ty cũ của tôi cũng từng có chuyện tương tự. Người dùng truy cập nhầm dữ liệu của khách hàng khác; nguyên nhân là do một nhân viên sai lầm cố gắng live debug trực tiếp trong production realtime (mà tôi từng phản đối trong buổi phỏng vấn). Loại sự cố này cực kỳ khó để truy vết và xử lý.
    • Có nghi ngờ rằng lúc sự cố, DynamoDB đã vào trạng thái không nhất quán tạm thời và kéo theo cả IAM credentials bị lỗi nữa; nếu đúng thì đây là vấn đề nghiêm trọng. Không biết có link nào tương tự để tham khảo không?
    • Nếu có bằng chứng liên quan thì hãy chia sẻ. Cực kỳ sốc.
    • Gần đây tôi lại nhớ xem có vấn đề tương tự của ChatGPT không. Cảm giác có chút giống nhau.
    • Sự cố an ninh như này nghiêm trọng hơn nhiều so với sự cố tạm thời của một dịch vụ thông thường.

  • Bình thường thì vụ việc này có thể chỉ là trùng hợp, nhưng phần lớn nguyên nhân thường là access key bị lộ. Cũng có trường hợp bị lộ mật khẩu tài khoản console chưa bật MFA, nhưng hiếm hơn.

  • Trong tình huống hoảng loạn, con người dễ bị phishing nhất. Cần reset toàn bộ mật khẩu và báo ngay cho AWS support. Họ thường giải quyết tốt nếu có lòng tin.

  • Region us-east-1 lớn hơn tưởng tượng. Theo thông tin công khai gần đây, có tới 159 data center. Có thể có hàng triệu account tập trung ở đây. Dù hiện tượng này có thể liên quan đến lỗi AWS, nhưng cá nhân tôi vẫn nghĩ khả năng là trùng hợp cao hơn.

    • 159 cái nghe thật lạ. Nếu có nguồn tham khảo thì share giúp.

  • Nghe có vẻ hơi lạ, nhưng nếu ai đó gửi API key cho tôi, có lẽ tôi có thể kiểm tra nó có nằm trong danh sách leak không.

    • Tôi biết đây là đùa, nhưng vẫn muốn nhắc cẩn thận vì đây là điểm quan trọng. Ngay cả khi là đùa, đừng nhắc tới việc chia sẻ API key hoặc credentials. Có người có thể hiểu theo nghĩa nghiêm túc nên cần cẩn trọng.