# T1053.006 - Systemd Timers
## Técnica Pai
Esta é uma sub-técnica de [[ Job]].
## Descrição
Adversários podem abusar de **systemd timers** para agendar a execução inicial ou recorrente de código malicioso em sistemas Linux modernos. Os timers do systemd são arquivos de unidade com extensão `.timer` que controlam serviços correspondentes, funcionando como uma alternativa mais poderosa e flexível ao [[t1053-003-cron|Cron]]. Eles podem ser configurados para disparar em eventos de calendário específicos ou após um intervalo relativo a um ponto de partida, e podem ser ativados remotamente via `systemctl` - inclusive por [[t1021-004-ssh|SSH]].
Cada arquivo `.timer` exige um arquivo `.service` de mesmo nome vinculado a ele. Arquivos `.service` são unidades gerenciadas pelo sistema init do Linux, responsáveis por iniciar, parar e monitorar processos. Os timers com privilégios elevados são instalados em `/etc/systemd/system/` ou `/usr/lib/systemd/system/`, enquanto timers no contexto de usuário ficam em `~/.config/systemd/user/`, dispensando acesso root.
Um adversário pode usar timers para executar código malicioso na inicialização do sistema ou de forma periódica, estabelecendo [[t1543-002-systemd-service|persistência via Systemd Service]]. Timers instalados em caminhos privilegiados garantem persistência com privilégios de root. A criação de timers no contexto de usuário, por sua vez, oferece persistência silenciosa sem necessidade de escalonamento de privilégio.
**Contexto Brasil/LATAM:** A adoção crescente de Linux em ambientes corporativos e de nuvem na América Latina - especialmente em servidores de aplicação, contêineres e ambientes de desenvolvimento - torna o abuso de systemd timers cada vez mais relevante. Grupos que operam ransomware como serviço têm explorado essa técnica para garantir re-execução de payloads mesmo após reinicializações de sistemas Linux em provedores de nuvem regionais.
## Attack Flow
```mermaid
graph TB
A[Acesso Inicial ao Sistema Linux] --> B[Criação de .timer e .service maliciosos]
B --> C{Nível de Privilégio}
C -->|Root| D["/etc/systemd/system/<br/>ou /usr/lib/systemd/system/"]
C -->|Usuário| E["~/.config/systemd/user/"]
D --> F[systemctl enable --now malware.timer]
E --> F
F --> G["ESTA TÉCNICA: T1053.006<br/>Execução Agendada via Timer"]
G --> H[Execução Periódica do Payload]
H --> I[Persistência após Reboot]
H --> J[Escalada de Privilégio via SYSTEM]
I --> K[C2 Beacon / Exfiltração]
J --> K
```
## Como Funciona
1. **Preparação** - O adversário obtém acesso ao sistema (via exploração, credencial comprometida ou movimento lateral por [[t1021-004-ssh|SSH]]) e prepara dois arquivos de unidade systemd: um `.timer` definindo o agendamento e um `.service` descrevendo o que executar.
2. **Instalação** - Os arquivos são copiados para o caminho adequado (`/etc/systemd/system/` para persistência root, `~/.config/systemd/user/` para persistência de usuário). O timer é habilitado com `systemctl enable` e iniciado com `systemctl start` ou o flag `--now`.
3. **Pós-execução** - O systemd registra o timer como uma unidade ativa, disparando automaticamente o serviço vinculado no intervalo configurado. O payload pode ser um beacon [[t1105-ingress-tool-transfer|baixado de C2]], um script de mineração (ver [[t1496-resource-hijacking|Sequestro de Recursos]]) ou um stager de ransomware.
**Exemplo de timer malicioso:**
```ini
# /etc/systemd/system/updaté-check.timer
[Unit]
Description=System Updaté Check
[Timer]
OnBootSec=2min
OnUnitActiveSec=15min
Unit=updaté-check.service
[Install]
WantedBy=timers.target
```
## Detecção
**Fontes de dados:** Logs do systemd (`journalctl`), auditd, Sysmon for Linux (EventID 11 - FileCreaté), monitoramento de integridade de arquivos (FIM), SIEM com ingestão de logs Linux.
```yaml
title: Criação Suspeita de Systemd Timer
id: a1b2c3d4-e5f6-7890-abcd-ef1234567890
status: experimental
description: >
Detecta criação de arquivos .timer em diretórios systemd fora de
jánelas de manutenção conhecidas ou por usuários não-privilegiados.
logsource:
product: linux
category: file_event
detection:
selection:
TargetFilename|endswith: '.timer'
TargetFilename|contains:
- '/etc/systemd/system/'
- '/usr/lib/systemd/system/'
- '/.config/systemd/user/'
filter_legitimate:
Image|contains:
- '/usr/bin/apt'
- '/usr/bin/dpkg'
- '/usr/bin/rpm'
condition: selection and not filter_legitimate
falsepositives:
- Instalação legítima de pacotes via gerenciador de pacotes
- Scripts de configuração de infra (Ansible, Chef, Puppet)
level: medium
tags:
- attack.persistence
- attack.t1053.006
```
**Sinais de alerta adicionais:**
- Arquivos `.timer` ou `.service` criados em diretórios systemd por processos que não são gerenciadores de pacotes
- Execução de `systemctl enable` por conta de usuário comum em horário incomum
- Serviços systemd referênciando caminhos em `/tmp`, `/dev/shm` ou diretórios de usuário
- Timer com `OnBootSec` curto (< 60s) e `OnUnitActiveSec` muito frequente (< 5min)
## Mitigação
| Mitigação | Recomendação |
|-----------|-------------|
| [[m1022-restrict-file-and-directory-permissions\|M1022 - Restrict File and Directory Permissions]] | Restringir escrita em `/etc/systemd/system/` e `/usr/lib/systemd/system/` a processos de empacotamento autorizados. Monitorar modificações via auditd com regras de `inotify`. |
| [[m1018-user-account-management\|M1018 - User Account Management]] | Limitar quais usuários podem usar `systemctl` para habilitar/iniciar unidades. Considerar `sudo` granular via `/etc/sudoers.d/`. |
| [[m1026-privileged-account-management\|M1026 - Privileged Account Management]] | Aplicar o princípio do menor privilégio - contas de serviço não devem ter permissão de criar ou modificar unidades systemd. |
## Referências
*Fonte: [MITRE ATT&CK - T1053.006](https://attack.mitre.org/techniques/T1053/006)*