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:

git clone https://github.com/PaloAltoNetworks/Unit42-timely-threat-intel.git
cd Unit42-timely-threat-intel
ls -1 | tail -10

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:

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

Method 1 — Full clone (recommended)

git clone https://github.com/PaloAltoNetworks/Unit42-timely-threat-intel.git
cd Unit42-timely-threat-intel

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:

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:

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

ls | wc -l

370

head -1 README.md

# 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

~/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.

# 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:

Re-fanging is a search-and-replace job. A minimal sed pipeline:

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:

# .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.

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:

YYYY-MM-DD-<short-description>.<txt|md>

Examples drawn directly from the repo:

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)

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)

# 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:

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

grep -Eio '[a-f0-9]{64}' 2024-02-27-IOCs-for-Akira-Ransomware.txt | sort -u

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:

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:

ls | grep -i 'IcedID'

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:

grep -lir 'Stately Taurus' .

./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

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

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:

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

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

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:

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:

git log --oneline 2025-10-16-Multi-Stage-Android-Malware-Campaign.md

a1b2c3d 2025-10-16-Multi-Stage-Android-Malware-Campaign.md added

Use the URL form https://github.com/PaloAltoNetworks/Unit42-timely-threat-intel/blob/<commit-sha>/<filename> — 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:

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 ("<hash> (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.