Sent the victim computer identifier in a User-Agent string back to the C2 server every 10 minutes.1
Scheduled Transfer T1029
- Tactic
- Exfiltration
- Platforms
- Linux, macOS, Windows
- Version
- 1.1
- Created
- 31 May 2017
- Last modified
- 24 October 2025
Adversaries may schedule data exfiltration to be performed only at certain times of day or at certain intervals. This could be done to blend traffic patterns with normal activity or availability.
Scheduled Transfer MITRE reference T1029
1 group has been recorded using this technique. Newest first; each entry carries MITRE’s procedure text and a link to the group’s full record. Click a name to filter the rules below.
All 1 groups for this technique
17 software entries are documented implementing this technique. MITRE files each as a tool or as malware; newest first, then by how many groups carry them.
Can configure its agent to work only in specific time frames.1
Can pause C2 communications for a specified time.1
Has the ability to wait for a specified time interval between communicating with and executing commands from C2.1
Contacts its C2 based on a scheduled timing set in its configuration.1
Can set itself to sleep before requesting a new command from C2.1
Has sent data back to C2 every 8 hours.1
All 17 software entries for this technique · 6 newest in this preview
Offense vs defense T1029
Is defensive coverage keeping up with adversary use? Eight counts, each ranked against all 697 ATT&CK techniques. Attack sits left, defense right, so a shape leaning left means adversaries are better documented here than defenders are equipped. Hover any spoke for its percentile and the share of techniques that have more. The timeline below shows when each side arrived.
Scheduled Transfer detection strategy DET0399
MITRE names one behaviour worth catching for this technique and breaks it into 3 analytics, one per platform. Each carries the log sources it needs and the fields you tune per environment.
Detection Strategy for Scheduled Transfer and Recurrent Exfiltration Patterns
AN1118 · Windows
Recurring network exfiltration initiated by scheduled or script-based processes exhibiting time-based regularity and consistent external destinations.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| Scheduled Job MetadataDC0005 | WinEventLog:System | EventCode=106, 200 |
| Process CreationDC0032 | WinEventLog:Sysmon | EventCode=1 |
| Network Connection CreationDC0082 | WinEventLog:Sysmon | EventCode=3, 22 |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| TimeWindow | Duration threshold to consider a connection repetitive (e.g., same hour daily) |
| DestIPAllowlist | Known external destinations to exclude (e.g., approved SFTP/backup servers) |
| ParentProcessBaseline | Allowlisted job runners or scripts known to schedule legitimate transfers |
AN1119 · Linux
Detection of cron-based or script-based recurring transfers where the same script, user, or destination reappears at predictable intervals.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| Scheduled Job MetadataDC0005 | linux:cron | cron activity |
| Process CreationDC0032 | auditd:SYSCALL | execve |
| Network Connection CreationDC0082 | NSM:Flow | Outbound Connections |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| ScriptPathRegex | Path patterns for shell scripts responsible for scheduled transfers |
| CronIntervalThreshold | Minimum repetition frequency (e.g., 24h for daily jobs) |
| ExfilUserContext | Suspicious or unexpected users launching scheduled transfers |
AN1120 · macOS
LaunchAgent or launchd recurring jobs initiating data transfer to consistent external IPs or domains with repeat timing signatures.
Log sources
The data this analytic draws on. You do not need every component — each one you already collect covers part of it. Each links to its ATT&CK record.
| Data component | Name | Channel |
|---|---|---|
| Scheduled Job MetadataDC0005 | macos:launchd | launchd.plist and logs |
| Process CreationDC0032 | macos:endpointsecurity | ES_EVENT_TYPE_NOTIFY_EXEC |
| Network Traffic FlowDC0078 | macos:unifiedlog | networkd or com.apple.network |
Tunable fields
MITRE calls these the analytic’s mutable elements: the thresholds and filters you set for your own environment.
| Field | What you tune |
|---|---|
| AgentPathPatterns | Regex for job locations like ~/Library/LaunchAgents/ |
| RepeatIntervalDelta | Time-based logic to determine schedule (e.g., ~24h ± 5m) |
| UserHomeJobs | Transfers originating from non-admin user context |
Certain commands are frequently used by malicious actors and infrequently used by normal users. By looking for execution of these commands in short periods of time, we can not only see when a malicious user was on the system but also get an idea of what they were doing.
D3FEND techniques
The defensive countermeasure this analytic implements, in MITRE’s D3FEND ontology.
| ID | Name |
|---|---|
| D3-PLA | Process Lineage Analysis |
Data model references
The CAR data model objects, actions and fields the logic reads. Map these to your own schema before implementing.
| Object | Action | Field |
|---|---|---|
| process | create | hostname |
| process | create | ppid |
| process | create | exe |
Implementations
Pseudocode is the canonical logic; the rest are CAR’s translations into vendor query languages.
processes = search Process:Create reg_processes = filter processes where (exe == "arp.exe" or exe == "at.exe" or exe == "attrib.exe" or exe == "cscript.exe" or exe == "dsquery.exe" or exe == "hostname.exe" or exe == "ipconfig.exe" or exe == "mimikatz.exe" or exe == "nbstat.exe" or exe == "net.exe" or exe == "netsh.exe" or exe == "nslookup.exe" or exe == "ping.exe" or exe == "quser.exe" or exe == "qwinsta.exe" or exe == "reg.exe" or exe == "runas.exe" or exe == "sc.exe" or exe == "schtasks.exe" or exe == "ssh.exe" or exe == "systeminfo.exe" or exe == "taskkill.exe" or exe == "telnet.exe" or exe == "tracert.exe" or exe == "wscript.exe" or exe == "xcopy.exe") reg_grouped = group reg by hostname, ppid where(max time between two events is 30 minutes) output reg_grouped
Sigma version of the above pseudocode, with some modifications.
DNIF version of the above pseudocode.
_fetch * from event where $LogName=WINDOWS-SYSMON AND $EventID=1 AND $App=regex(arp\.exe|at\.exe|attrib\.exe|cscript\.exe|dsquery\.exe|hostname\.exe|ipconfig\.exe|mimikatz.exe|nbstat\.exe|net\.exe|netsh\.exe|nslookup\.exe|ping\.exe|quser\.exe|qwinsta\.exe|reg\.exe|runas\.exe|sc\.exe|schtasks\.exe|ssh\.exe|systeminfo\.exe|taskkill\.exe|telnet\.exe|tracert\.exe|wscript\.exe|xcopy\.exe)i group count_unique $App limit 100 >>_agg count >>_checkif int_compare Count > 1 include
LogPoint version of the above pseudocode.
norm_id=WindowsSysmon event_id=1 image IN ["*\arp.exe", "*\at.exe", "*\attrib.exe", "*\cscript.exe", "*\dsquery.exe", "*\hostname.exe", "*\ipconfig.exe", "*\mimikatz.exe", "*\nbstat.exe", "*\net.exe", "*\netsh.exe", "*\nslookup.exe", "*\ping.exe", "*\quser.exe", "*\qwinsta.exe", "*\reg.exe", "*\runas.exe", "*\sc.exe", "*\schtasks.exe", "*\ssh.exe", "*\systeminfo.exe", "*\taskkill.exe", "*\telnet.exe", "*\tracert.exe", "*\wscript.exe", "*\xcopy.exe"] | chart count() as cnt by host | search cnt > 1
Unit tests
CAR’s own validation procedures for this analytic.
Within a command window, execute several of the commands in quick succession.
["ipconfig /all","hostname","systeminfo","reg.exe Query HKLM\\Software\\Microsoft"]
Network intrusion detection and prevention systems that use network signatures to identify traffic for specific adversary command and control infrastructure and malware can be used to mitigate activity at the network level. Signatures are often for unique indicators within protocols and may be based on the specific obfuscation technique used by a particular adversary or tool, and will likely be different across various malware families and versions. Adversaries will likely change tool command and control signatures over time or construct protocols in such a way to avoid detection by common defensive tools.