# Unit 42 Timely Threat Intel User Guide The `Unit42-timely-threat-intel` repository is a public, GitHub-hosted feed of indicators of compromise (IOCs) and short campaign writeups published by Palo Alto Networks' Unit 42 research team. It accompanies the team's social-media posts (LinkedIn and X/Twitter) and gives SOC analysts, threat hunters, incident responders, and security researchers a citable, version-controlled source of file hashes, network observables, domains, and short technical narratives covering active malware, phishing, and scam campaigns. This guide explains what is actually in the repo, how to clone and navigate it, how to fold the indicators into your detection stack, and what to watch out for when you do. > [!NOTE] > This repo is **not** software. It contains **370 files** at the top level — 367 dated threat-intel reports, plus `README.md`, `LICENSE` (GPL-3.0), and `SUPPORT.md`. There is nothing to install, build, or run. The "tool" is the dataset and the consistent file format described below. ## 1. Quick Start ### What this repo gives you - Roughly **367 dated threat-intel files** spanning **2020-08-20** through **2026-04-21**, each named after the publication date and the campaign or malware family it covers. - File extensions are almost entirely `.txt`, with a small number of `.md` files reserved for longer, formatted writeups (for example, `2025-10-16-Multi-Stage-Android-Malware-Campaign.md` and `2025-12-15-real-world-case-of-malicious-indirect-prompt-injection.md`). - Each file follows a predictable internal layout: a date and short title header, an `AUTHOR(S)` block, `REFERENCES` to LinkedIn/Twitter posts, free-form `NOTES`/`DETAILS`, then one or more indicator blocks (SHA256 hashes, domains, URLs, IP addresses, file paths). - Network indicators are **defanged** — `.` becomes `[.]`, `http` becomes `hxxp` — to prevent accidental clicks and to slip past corporate URL scanners. You re-fang them before feeding them to detection tools. ### The 60-second recipe Clone the repo, list the files, and open the most recent one: ```bash git clone https://github.com/PaloAltoNetworks/Unit42-timely-threat-intel.git cd Unit42-timely-threat-intel ls -1 | tail -10 ``` ```text 2026-03-30-KIMWOLF-V7-IoT.txt 2026-03-31-SHub-Stealer-Activity.txt 2026-04-02-Threat-Actor-Targets-Military-Entities.txt 2026-04-07-Montana-Empire.txt 2026-04-13-LORIKAZZ-ANDROID-IOT.txt 2026-04-15-SEO-Poisoning.txt 2026-04-21-LummaStealer-Delivered-Via-Malicious-Search-Results.txt LICENSE README.md SUPPORT.md ``` Open the newest file in your pager of choice: ```bash less 2026-04-21-LummaStealer-Delivered-Via-Malicious-Search-Results.txt ``` > [!TIP] > You do not need to clone. If you only want one report, the GitHub UI serves the raw text directly — for example, `https://raw.githubusercontent.com/PaloAltoNetworks/Unit42-timely-threat-intel/main/2026-04-21-LummaStealer-Delivered-Via-Malicious-Search-Results.txt` returns the file in plaintext, suitable for `curl` into an automation pipeline. ### Key features - **Source-of-truth IOCs** for active campaigns Unit 42 is publicly tracking, in the form Unit 42 themselves use. - **Date-stamped filenames** make sorting, diffing, and "show me everything from Q1 2026" trivial with `ls`, `find`, or `git log`. - **Defanged observables** safe to grep, paste into tickets, and embed in chat without triggering URL link expansion. - **Tracked threat actor names** in Unit 42's "celestial" naming scheme (for example, `Stately Taurus`, `Bitter Scorpius`, `Iron Taurus`, `Alloy Taurus`, `Boggy Serpens`, `Squeamish Libra`, `Dark Scorpius`, `White Lynx`, `Agent Serpens`) appear directly in filenames or report bodies. - **Cross-references** — each report links back to the Unit 42 LinkedIn/Twitter post that announced it, so you can trace claims back to their originating publication. - **GPL-3.0 licensed** — you may copy, redistribute, and incorporate the indicators into your own (also GPL-compatible) tooling. ### Prerequisites A working `git` install and any text editor or pager. That is the entire toolchain. ### What to try next - Section 4 (Core Usage) walks through the directory layout and the canonical internal format of an indicator file. - Section 5 (Common Tasks) is a recipe book — extract IOCs for one campaign, ingest YARA-style observables into your SIEM, diff two reports, contribute a new file. - Section 6 (Troubleshooting) covers the few real gotchas: defanged-string handling, EDR scanners triggering on hash strings, file-naming inconsistencies (see GitHub issue #2). ## 2. Installation There is no installation step in the conventional sense. "Installing" this repo means cloning it (or downloading a single file) and putting it somewhere your tools can read. ### System requirements | Requirement | Detail | |---|---| | Disk | A few hundred MB after clone. Per-file payloads are small (typically 1-30 KB), but `.git` history dominates because every report is a separate commit. | | Tools | `git` (any reasonably recent version) for the standard path; `curl` or `wget` if you only want individual files. | | Network | Outbound HTTPS to `github.com` and `raw.githubusercontent.com`. | | OS | Anything that runs `git`. The files are plaintext and use Unix line endings predominantly. | ### Method 1 — Full clone (recommended) ```bash git clone https://github.com/PaloAltoNetworks/Unit42-timely-threat-intel.git cd Unit42-timely-threat-intel ``` ```text Cloning into 'Unit42-timely-threat-intel'... remote: Enumerating objects: ... Receiving objects: 100% (...), done. ``` > [!IMPORTANT] > Antivirus and EDR products on your workstation may quarantine the working directory **during clone or pull**. The reports list real malware SHA256 hashes, malicious URLs, and snippets of malicious code as plaintext strings. Endpoint scanners that match on string-form hashes or URLs will treat the repo as a threat. See section 6 for how to work around this safely. ### Method 2 — Shallow clone (for automation) If you only need the latest state (no history), shallow-clone: ```bash git clone --depth=1 https://github.com/PaloAltoNetworks/Unit42-timely-threat-intel.git ``` This skips ~5 years of commits and is significantly faster for CI jobs that run on every push to your detection-rules repo. ### Method 3 — Single-file fetch For a one-off lookup or a feed that polls GitHub for the latest report: ```bash curl -sSL \ "https://raw.githubusercontent.com/PaloAltoNetworks/Unit42-timely-threat-intel/main/2026-04-21-LummaStealer-Delivered-Via-Malicious-Search-Results.txt" \ -o lumma-2026-04-21.txt ``` > [!TIP] > The GitHub API endpoint `https://api.github.com/repos/PaloAltoNetworks/Unit42-timely-threat-intel/contents/` returns a JSON listing of every file at the root, which is convenient for "list everything published since YYYY-MM-DD" automations. Filter the response by `name`, since each entry's `name` field starts with the publication date in `YYYY-MM-DD` format. ### Method 4 — GitHub web UI The lowest-friction path of all: open `https://github.com/PaloAltoNetworks/Unit42-timely-threat-intel`, click the file you want, and click **Raw** to get the plaintext URL. This is fine for ad-hoc lookups and for browsing the chronological list. ### Verifying the clone ```bash ls | wc -l ``` ```text 370 ``` ```bash head -1 README.md ``` ```text # Unit42-Timely-Threat-Intel ``` If those numbers and lines come back as expected, your clone is intact. ## 3. Configuration There is no config file, no environment variable, and no daemon. Configuration here means **deciding how you store, refresh, and query the dataset locally**, and how you defang or re-fang strings as they cross your tooling boundary. ### Recommended local layout ```text ~/threat-intel/ Unit42-timely-threat-intel/ # the clone scripts/ # your extraction helpers (optional) exports/ # CSV/STIX you generate (optional) ``` Keeping the upstream clone untouched and writing derived data into sibling folders means a `git pull` never conflicts with your work product. ### Refresh cadence Unit 42 publishes irregularly — new files have appeared roughly **weekly to several-times-per-week** across the 2020-2026 history. A `git pull` on a 30-minute or 1-hour cron is more than fast enough to catch new posts shortly after publication. Pulling more aggressively wastes API quota. ```bash # Hourly cron entry 0 * * * * cd ~/threat-intel/Unit42-timely-threat-intel && git pull --ff-only --quiet ``` ### Defanging conventions you must respect Every URL, domain, and IP in this dataset is defanged with the following substitutions: | Defanged | Real | Where it appears | |---|---|---| | `[.]` | `.` | Domains, IPs | | `hxxp://` | `http://` | URLs | | `hxxps://` | `https://` | URLs | | `[:]` | `:` | Sometimes used in URL prefixes | Re-fanging is a search-and-replace job. A minimal `sed` pipeline: ```bash sed -e 's/\[\.\]/./g' -e 's|hxxp|http|g' -e 's/\[:\]/:/g' input.txt > refanged.txt ``` > [!CAUTION] > Only re-fang in **isolated, non-routable** environments. The moment you re-fang, your editor's link-preview, your terminal multiplexer's URL parser, your chat client paste, or your browser autosuggest may visit the live malicious infrastructure. Keep refanged data in folders that are excluded from indexing/preview tools. ### Optional: ignore patterns for your own repo If you wrap this repo's data inside your own internal repo, add an exclusion so your scanners do not flag the directory as a finding: ```text # .gitignore or scanner-ignore Unit42-timely-threat-intel/ exports/ ``` For full deployment-side configuration (storage layouts, signing pipelines, automated ingest into TIPs), see the Administrator Guide. ## 4. Core Usage ### 4.1 Top-level directory layout The repository is **flat**. There are no subdirectories — every threat-intel report lives directly at the root, alongside `README.md`, `LICENSE`, and `SUPPORT.md`. ```text Unit42-timely-threat-intel/ ├── 2020-08-20-IOCs-for-Emotet-infection-with-Qakbot.txt ├── 2020-08-24-IOCs-for-Trickbot-gtag-ono66.txt ├── 2020-08-25-IOCs-for-Emotet-with-Trickbot.txt ├── ... (367 dated reports total, 2020-08 through 2026-04) ├── 2026-04-15-SEO-Poisoning.txt ├── 2026-04-21-LummaStealer-Delivered-Via-Malicious-Search-Results.txt ├── LICENSE ├── README.md └── SUPPORT.md ``` > [!NOTE] > The flat layout is intentional and load-bearing. Sorting alphabetically sorts chronologically (filenames begin with `YYYY-MM-DD`), so `ls`, `find -name`, and `git log --name-only` all double as a timeline view. There is no "by-actor" or "by-malware-family" folder — those axes live in the filename text. ### 4.2 Filename convention Filenames generally follow: ```text YYYY-MM-DD-. ``` Examples drawn directly from the repo: | Filename | What it tells you | |---|---| | `2020-08-20-IOCs-for-Emotet-infection-with-Qakbot.txt` | IOCs for an Emotet infection that pulled Qakbot as a follow-up payload, published 2020-08-20. | | `2024-02-27-IOCs-for-Akira-Ransomware.txt` | IOCs and notes about updates to the Akira ransomware codebase. | | `2025-04-25-IOCs-for-Blitz-malware.txt` | Tracking notes and SHA256s for the "Blitz" Windows bot abusing Hugging Face. | | `2025-10-16-Multi-Stage-Android-Malware-Campaign.md` | Long-form Markdown writeup of an Android APK distribution chain. | | `2026-03-12-Vishing-Campaigns-Lead-to-Data-Theft-and-Extortion.txt` | Notes and IOCs for vishing campaigns ending in extortion. | | `2026-04-21-LummaStealer-Delivered-Via-Malicious-Search-Results.txt` | LummaStealer delivery via SEO-poisoned YubiKey Manager searches. | Most files use **kebab-case** descriptions; a handful (especially newer files in 2025-2026) use mixed case or all-caps for emphasis (for example, `2026-03-19-THE-GHOST-IN-CAMPAIGN.txt`, `2026-03-30-KIMWOLF-V7-IoT.txt`). Treat your name-matching as **case-insensitive** to be safe. > [!WARNING] > A small number of filenames have minor irregularities documented by the community as **GitHub issue #2 — "Wrong date in name of IoCs file"** (closed). If you build automation that parses the date from the filename, validate that `YYYY-MM-DD` against the **first line** of the file body (which always restates the date), and prefer the body when they disagree. ### 4.3 Internal report structure Reports follow one of two formats. The **classic plaintext format** (the majority — used in `.txt` files) and the **Markdown format** (used in `.md` files for longer writeups). Both carry the same logical sections: #### Classic plaintext format (`.txt`) ```text 2024-02-27 (TUESDAY): UPDATES TO AKIRA RANSOMWARE CODEBASE AUTHOR: - Daniel Bunce REFERENCES: - https://www.linkedin.com/posts/unit42_... - https://twitter.com/Unit42_Intel/status/... NOTES: - We recently identified updates to the Akira ransomware codebase. - Updates include leveraging open source crypto libraries... SHA256 HASHES FOR AKIRA RANSOMWARE: - 08207409e1d789aea68419b04354184490ce46339be071c6c185c75ab9d08cba - 2727c73f3069457e9ad2197b3cda25aec864a2ab8da3c2790264d06e13d45c3d - ... ``` Section headings are uppercase, terminated by a colon, and followed by a blank line. Indicators are bullet-listed with a leading `-` and one space. #### Markdown format (`.md`) ```markdown # 2025-12-15 (Monday): Real-World Example of Malicious Indirect Prompt Injection ## Authors: - Beliz Kaleli, Shehroze Farooqi, Alex Starov ## References: - [https://www.linkedin.com/posts/...](https://www.linkedin.com/posts/...) - [https://x.com/Unit42_Intel/status/...](https://x.com/Unit42_Intel/status/...) ## Notes: - We've identified a recent real-world example of malicious indirect prompt injection. - ... ``` Markdown reports use the same logical layout but lean on H1/H2 headings and fenced code blocks. They are always preferred for reports that include code samples, command sequences, or attack-chain diagrams. ### 4.4 Indicator types you will encounter Across the corpus, the following indicator categories appear in section headings — these are the names Unit 42 uses, so they are also the strings you grep for: | Category | Typical heading text | Example values | |---|---|---| | File hashes | `SHA256 HASHES`, `SHA256 hash:` | `86d480ab25fee4635d9de621cfd8f3866e047465bfbc8afeac4bfe33591c7190` | | Domains | `Domains`, `DOMAINS`, embedded in `INFECTION TRAFFIC` | `paul-und-emily[.]de`, `verifydl[.]top` | | URLs | `URLs`, `File location:` | `hxxp://example[.]com/path/`, `hxxps://yubico-app[.]com/yubikey-manager[.]php` | | IP addresses | `IPv4 Addresses`, embedded in traffic blocks | `81.169.145[.]72`, `192.250.245[.]109` | | File paths on victim host | `File location:` | `C:\Users\[username]\AppData\Roaming\...\qyomfwmn.exe` | | Network traffic blobs | `INFECTION TRAFFIC`, e.g. `EMOTET INFECTION TRAFFIC` | `81.169.145[.]72 port 80 - paul-und-emily[.]de - GET /...` | | File metadata | `File size`, `File name`, `File description` | `242,942 bytes`, `doc 2020_08_20.doc` | | Timing | `START TIME OF THE INFECTION` | `2020-08-20 15:43:59 UTC` | | Threat-actor attribution | Mentioned in body, sometimes in title | `Stately Taurus`, `Bitter Scorpius`, `Boggy Serpens`, `Iron Taurus`, `Dark Scorpius`, `White Lynx`, `Alloy Taurus`, `Agent Serpens`, `Squeamish Libra` | > [!NOTE] > The dataset does **not** ship YARA rules, Snort/Suricata signatures, STIX bundles, MISP exports, or MITRE ATT&CK technique tables as separate artifacts. Where ATT&CK techniques are referenced (for example, "DLL sideloading", "Process Hollowing", "RunPE"), they appear as inline prose in the `NOTES`/`DETAILS` sections, not as machine-readable tags. ### 4.5 Reading a report end-to-end Pick `2026-04-21-LummaStealer-Delivered-Via-Malicious-Search-Results.txt` as a representative example. The flow is: 1. **Header line** — date, weekday, and short title. 2. **`AUTHOR(S):`** — the Unit 42 researchers who published it (here: Jonny Westfall, Alex Payne). 3. **`NOTES:`** — bullet-form summary of how the campaign works (initial-access vector, execution chain, evasion, payload, attribution rationale). 4. **`DETAILS:`** — sometimes prose, sometimes an ASCII tree of the execution chain. 5. **`INDICATORS:`** — categorized observables: SHA256 hashes (with role labels — "sideloaded DLL", "malicious"), defanged domains, defanged URLs. A reading-for-action workflow looks like: confirm the date is recent enough to act on; skim `NOTES`; jump to `INDICATORS`; export the hashes and domains into your TIP or detection stack. ## 5. Common Tasks ### 5.1 Extract every SHA256 from one report ```bash grep -Eio '[a-f0-9]{64}' 2024-02-27-IOCs-for-Akira-Ransomware.txt | sort -u ``` ```text 08207409e1d789aea68419b04354184490ce46339be071c6c185c75ab9d08cba 2727c73f3069457e9ad2197b3cda25aec864a2ab8da3c2790264d06e13d45c3d 2db4a15475f382e34875b37d7b27c3935c7567622141bc203fde7fe602bc8643 ... ``` The `64-hex-chars` pattern reliably matches SHA256 strings while skipping shorter MD5 or SHA1 fragments. Pipe to `wc -l` to count, or to a file for ingestion. > [!TIP] > Bake this into a reusable shell function. Append to `~/.bashrc`: > ```bash > u42_sha256() { grep -Eiroh '[a-f0-9]{64}' "$1" | sort -u; } > ``` > Then `u42_sha256 .` extracts and deduplicates every SHA256 across the entire repo at once. ### 5.2 Find every report mentioning a specific malware family or campaign Filenames carry the campaign label, so a filename grep is fastest: ```bash ls | grep -i 'IcedID' ``` ```text 2021-03-01-IOCs-from-IcedID-with-Cobalt-Strike.txt 2021-03-15-IOCs-from-IcedID-infection.txt 2021-03-24-IOCs-for-IcedID-infection-with-Cobalt-Strike.txt 2021-04-12-IOCs-for-IcedID-infection.txt ... ``` For matches inside file bodies (campaign name only mentioned in body), use `grep -lir`: ```bash grep -lir 'Stately Taurus' . ``` ```text ./2025-02-25-IOCs-Stately-Taurus-Pubload-activity.txt ./2025-11-10-IOCs-from-Stately-Taurus-activity.txt ``` ### 5.3 Build a defanged-to-real domain list for a single report ```bash grep -Eo '\b[a-z0-9-]+(\[\.\][a-z0-9-]+)+\b' \ 2026-04-21-LummaStealer-Delivered-Via-Malicious-Search-Results.txt \ | sed 's/\[\.\]/./g' \ | sort -u ``` ```text verifydl.top yubico-app.com ``` This is the minimum-viable refanger for domain blocklists. For URLs, extend the pattern to capture the `hxxps://` prefix and the path. ### 5.4 Ingest IOCs into a SIEM The repo emits plaintext, not STIX or CSV, so ingestion is a transform step. A general pattern: 1. `git pull` on a cron schedule. 2. For each new file (`git diff --name-only HEAD~1 HEAD`), run extractors for each indicator type (SHA256, domain, URL, IPv4). 3. Refang each output. 4. Format as your SIEM's expected feed (CSV, JSON list, or TAXII). 5. Push to your indicator API. A starter Python sketch: ```python import re, pathlib HASH_RE = re.compile(r'\b[a-f0-9]{64}\b', re.I) DOMAIN_RE = re.compile(r'\b[a-z0-9-]+(?:\[\.\][a-z0-9-]+)+\b', re.I) IP_RE = re.compile(r'\b(?:\d{1,3}\[\.\]){3}\d{1,3}\b') def refang(s: str) -> str: return s.replace('[.]', '.').replace('hxxp', 'http').replace('[:]', ':') for path in pathlib.Path('.').glob('20*-*.txt'): text = path.read_text(encoding='utf-8', errors='replace') print(path.name, { 'sha256': sorted(set(HASH_RE.findall(text))), 'domains': sorted({refang(m) for m in DOMAIN_RE.findall(text)}), 'ipv4': sorted({refang(m) for m in IP_RE.findall(text)}), }) ``` > [!IMPORTANT] > Add a per-indicator **decay/expiry** policy in your SIEM. Some IOCs (sinkhole IPs, takedowns, expired domains) become stale within weeks. Without expiry, you accrete false positives. A 30-90 day default plus an analyst-driven "keep" override is a common starting point. ### 5.5 Compare IOC overlap between two reports ```bash comm -12 \ <(grep -Eio '[a-f0-9]{64}' 2024-02-27-IOCs-for-Akira-Ransomware.txt | sort -u) \ <(grep -Eio '[a-f0-9]{64}' 2025-04-25-IOCs-for-Blitz-malware.txt | sort -u) ``` `comm -12` shows hashes present in **both** files. `-23` shows hashes only in the first; `-13` only in the second. This is how analysts spot infrastructure reuse across campaigns and across vendors. ### 5.6 Track everything published in a given month ```bash ls 2025-03-*.txt 2025-03-*.md 2>/dev/null ``` Or use `git log` to see when each file was first added — useful when filenames have been retro-edited: ```bash git log --diff-filter=A --name-only --since=2025-03-01 --until=2025-03-31 \ --pretty=format:'%h %ad %s' --date=short ``` ### 5.7 Cite a specific report at a stable revision When you reference a Unit 42 report in your own ticket, runbook, or detection rule, pin it to a commit so the link does not move under you: ```bash git log --oneline 2025-10-16-Multi-Stage-Android-Malware-Campaign.md ``` ```text a1b2c3d 2025-10-16-Multi-Stage-Android-Malware-Campaign.md added ``` Use the URL form `https://github.com/PaloAltoNetworks/Unit42-timely-threat-intel/blob//` — that link survives upstream renames and edits. ### 5.8 Contribute a correction Direct contributions are out of scope per the repo's `SUPPORT.md` ("released as-is"; no normal support channel). The community-supported path is to file a GitHub issue — see issue #2 (closed: a date-in-filename correction) for an example of the kind of fix Unit 42 has accepted in the past: ```text https://github.com/PaloAltoNetworks/Unit42-timely-threat-intel/issues/new ``` State the file, the line, and the proposed correction. Keep the issue minimal and factual. ## 6. Troubleshooting > [!WARNING] > The single biggest source of friction with this repo is **endpoint security software treating its contents as live malware**. Plan for it before you clone, not after. ### Error: clone aborts mid-way; `.git` shows partial objects **Cause:** Your AV/EDR product flagged a hash string, a malicious URL, or an embedded base64 fragment in one of the report files (for example, `2025-12-15-real-world-case-of-malicious-indirect-prompt-injection.md` contains a base64 prompt-injection blob and HTML samples). **Solution:** 1. Check your endpoint product's quarantine / detection log for entries pointing into the clone path. 2. Add the destination directory to the product's exclusion list (path-based, not hash-based) **before** retrying. 3. `rm -rf` the partial clone and re-run `git clone`. **Prevention:** Clone into a path your security team has already exempted for analyst tooling — typically a dedicated research VM, an isolated workstation profile, or a path under `~/research/` registered with your EDR. ### Error: My SIEM imports the URLs but they are inert **Cause:** The strings are still defanged. `hxxps://example[.]com` is not a valid URL and most SIEMs match it as literal text only. **Solution:** 1. Refang during the extraction pipeline (see section 5.4). 2. Validate with one known sample: take a refanged URL, paste it into a URL-parser library — it should produce a valid scheme, host, and path. **Prevention:** Make refanging a single function in your ingestion code and unit-test it on a fixture of the real defanged forms (`[.]`, `[:]`, `hxxp`, `hxxps`). ### Error: Filename date does not match content date **Cause:** Documented in **GitHub issue #2** ("Wrong date in name of IoCs file") — a small number of files have a typo in the date field of the filename. The first line of the body contains the canonical date. **Solution:** Treat the **first non-empty line** of the file as the source-of-truth date. Parse a `YYYY-MM-DD` substring from that line; fall back to the filename only if the body header is missing. **Prevention:** Build your automation to favor file-body dates and to log a warning whenever the two disagree, so you can file an upstream issue and update your correction list. ### Error: My grep misses some hashes **Cause:** Some report bodies wrap hash values across whitespace inconsistencies, append role labels on the same line ("` (sideloaded DLL)- Requested malicious`"), or use different label phrasing across years. Anchored regexes that assume `^- ` or `^SHA256: ` will miss many matches. **Solution:** Use a content-based regex (`[a-f0-9]{64}` with case-insensitive matching) rather than a structural one. Match against the whole file with `grep -Eio`, then deduplicate with `sort -u`. **Prevention:** Maintain a fixture set of 5-10 representative files spanning early (2020), middle (2022-2023), and recent (2026) reports, and unit-test your extractors against all of them. ### Error: My link previewer auto-loaded a malicious URL **Cause:** A teammate pasted a refanged URL into a chat client, ticket system, or email. The platform's link unfurler followed it. **Solution:** 1. **Never refang inside chat/email/ticket platforms.** Paste the defanged form (`hxxps://malicious[.]example`) and let the consumer refang locally. 2. If you must produce a hyperlinked artifact (a written report), use a markdown code span around the URL: `` `hxxps://malicious[.]example` `` — this prevents most renderers from auto-linking. **Prevention:** Add a "no refanged URLs in chat" rule to your team's playbook. Refanging belongs in detection-pipeline code paths only. ### Error: I cannot tell which files are about a specific MITRE ATT&CK technique **Cause:** ATT&CK technique IDs (T-numbers) are **not** systematically tagged in this repo. Some reports describe a technique in prose ("DLL sideloading", "Process Hollowing", "Token duplication / `winlogon` token theft"), but you will not find `T1574.002` as a string match. **Solution:** Map by keyword, not by ATT&CK ID — for example, search for "DLL sideloading" or "process hollowing" in body text — and curate your own ATT&CK index as you go. **Prevention:** If technique-level slicing is critical to your workflow, layer a tagging step into your ingestion pipeline (LLM extraction or regex-keyword mapping) and write the tags into your TIP, not back into this repo. ### Error: I can't find a campaign I saw in a Unit 42 LinkedIn post **Cause:** Not every Unit 42 publication ships a corresponding file in this repo — the repo specifically supports posts "designed to disseminate timely threat intelligence data" and is community-supported, best-effort (per `SUPPORT.md`). **Solution:** Check the dates surrounding the post, search the body of nearby files for the LinkedIn/Twitter URL the post used, and fall back to the canonical Unit 42 blog at `https://unit42.paloaltonetworks.com/` for longer-form research that the repo does not cover. **Prevention:** Treat this repo as the **IOC companion** to social-media posts, not as the complete catalog of Unit 42 research. ## 7. FAQ **Q: Is this an IOC feed I can subscribe to?** Not in the traditional sense — there is no STIX/TAXII server, no RSS, and no JSON API. The closest equivalent is `git pull` on a schedule against the GitHub repo, plus optionally GitHub's per-file commit feed (`https://github.com/PaloAltoNetworks/Unit42-timely-threat-intel/commits/main.atom`) for change notifications. **Q: Are the indicators machine-readable?** Loosely. Filenames are predictable (`YYYY-MM-DD-...`), section headings inside files are reasonably consistent, and indicators can be extracted with regex (see section 5.4). There is no formal schema, no STIX export, and no MISP feed. Build your own normalizer. **Q: How often is the repo updated?** Irregularly, but historically several times per week to several times per month, with consistent flow from 2020-08 through the most recent files in 2026-04. There are quiet weeks and busy weeks; cadence tracks Unit 42's research output. **Q: Can I use these IOCs in a commercial product?** Subject to the **GPL-3.0 license** at the root of the repo. GPL-3.0 is a strong copyleft license — derived works that you distribute must also be GPL-3.0. Most analysts incorporate the indicators internally (which copyleft does not restrict), or treat the indicators themselves (facts/numbers) as outside the scope of copyright in their jurisdiction. Talk to legal before redistributing the dataset itself. **Q: Why are URLs and IPs written with `[.]` and `hxxp`?** This is industry-standard **defanging**. It prevents accidental clicks, stops most URL scanners from contacting live malicious infrastructure, and makes the strings safe to paste into tickets, chat, and email. You refang only at the boundary of a controlled detection or sandbox environment. **Q: Are file hashes in the reports safe to store?** Yes — a SHA256 is a 64-character hex string with no executable content. Some endpoint AV products will, however, **flag the string itself** because they string-match on known-bad hashes. If your AV does this, exclude the repo's directory from on-access scanning. **Q: Does the repo include the actual malware samples?** No. Only **hashes** and metadata are published. To obtain a sample for analysis, use a malware-sharing platform you already have access to (VirusTotal, MalwareBazaar, your team's sandbox), or contact Unit 42 through your Palo Alto Networks account team. **Q: What is the relationship between this repo and the Unit 42 blog?** The blog (`https://unit42.paloaltonetworks.com/`) carries deep, narrative research. This repo carries **IOC supporting material** for shorter, faster posts on LinkedIn and X/Twitter — the social-media-first distribution channel the team calls "timely threat intel." Each report in the repo links back to the originating social post. **Q: How do I report a wrong indicator or a wrong filename?** Open an issue at `https://github.com/PaloAltoNetworks/Unit42-timely-threat-intel/issues`. The bar for issues is low — issue **#2** was a single filename-date typo and was accepted. Keep the report factual and minimal. **Q: Why is there no `data/` or `iocs/` subdirectory?** The flat layout is deliberate. Filename prefix sorts chronologically, the descriptor portion of the filename labels the campaign, and there is no hierarchy that would survive across years (today's actor names rotate; a folder structure built around them would calcify quickly). The Administrator Guide discusses tradeoffs and operational implications. **Q: Can I get a different format — STIX, MISP, or CSV?** Not directly from upstream. You can build it: section 5.4 sketches a Python extractor, and section 5.7 explains how to pin to a stable commit so your derived dataset is reproducible. If you publish the derived feed, comply with GPL-3.0 attribution and notice requirements. **Q: I see `(no entry points detected)` — is the repo broken?** That message comes from a code-analysis tool that expected a software project. This repo is a **dataset**, not software, so there are no entry points to detect. The dataset itself is healthy. **Q: Where do I learn the methodology behind the IOCs (capture, analysis, attribution)?** The reports themselves contain analyst-level prose in their `NOTES`/`DETAILS` sections, especially the longer Markdown writeups. For deeper methodology, follow the `REFERENCES` link to the originating Unit 42 LinkedIn or X/Twitter post — those frequently cross-link to a longer Unit 42 blog article when one exists. --- _Generated April 2026 from PaloAltoNetworks/Unit42-timely-threat-intel at 31c6ed9. AI-generated documentation. The library is checked by sampling (three repositories so far); this guide was not individually reviewed. Verify against the project before relying on it. Unofficial, AI-generated guide for a Palo Alto Networks open-source repository; not reviewed by Palo Alto Networks._