Confirmed: This is Tor 0.4.8.12 for Windows x64. The `--service` install/remove options are documented Tor commands for Windows. The CreateService usage is part of Tor's own service-install feature.

I have enough to compile the report.

---

# Malware Triage Report — `6b866c187a0dee2fb751a8990d50dc1ed83f68e025720081e4d8e27097067dc8`

## Summary

The submitted file (#AID=186#) is a legitimate, non-malicious build of **The Tor Project's `tor.exe` daemon, version 0.4.8.12**, compiled for Windows x64 using `x86_64-w64-mingw32-cc`. It is a 64-bit PE, 8.98 MB, MSVC 2015 linker stub + MinGW-compiled object code, statically linked against OpenSSL and Zlib. No packing, no encryption layer, no embedded sub-files. The "suspicious" Yara/heuristic hits (TorUsage, CreateService, EnumerateProcesses, CryptoApiUsage, DownloaderApiUsage) are all expected behaviors of an authentic Tor client/relay build.

## Key Detections / IOCs

**Yara matches (all consistent with genuine Tor):**
- `TorUsage` – uses Tor protocol/library (this *is* Tor)
- `CreateService` – Tor implements `tor --service install/remove` on Windows
- `EnumerateProcesses` – standard
- `Zlib`, `MSVC_2015_linker` – informational

**Heuristic anomalies:**
- `CryptoApiUsage`, `DownloaderApiUsage` – consistent with a TLS network client
- High .text entropy (120) and many `XorInLoop` (1011) hits – expected from embedded crypto code (Curve25519, Ed25519, AES, SHA, etc.)
- `BigBufferNoXrefMediumToHighEntropy` (6 hits) – consensus parameters / consensus tables / GeoIP-like blobs typical of Tor

**IOCs / artifacts:**
- Version string: `tor 0.4.8.12` (@ ea 7136446)
- Build banner: `(on Tor 0.4.8.1...beaa7557c3c93ec)` (commit hash) (@ ea 7482896)
- Compiler banner: `x86_64-w64-mingw32-cc -m64 ... -DOPENSSL_PIC -DUNICODE -DOPENSSL_BUILDING_OPENSSL -DNDEBUG`
- Copyright: `Copyright (c) 2001-2004, Roger Dingledine ... 2007-2021, The Tor Project, Inc.`
- License: `This build of Tor is covered by the GNU General Public License (https://www.gnu.org/licenses/gpl-3.0.en.html)`
- URL strings: `https://www.torproject.org/`, `/tor/status-vote/current/consensus/`
- No C2 IPs/onion addresses hard-coded; only generic Tor protocol strings ("Onion address %s", "Rend stream is %s", "Attachstream to ...")

## Evidence

1. **High-level info** (#AID=186#): Standard PE32+ x64, MinGW-built. Sections are normal (`.text`, `.rdata`, `.buildid`, `.data`, `.pdata`, `.tls`, `.reloc`). `.buildid` is a MinGW-specific section — the `SectionNameUnknown` anomaly is harmless.
2. **Strings overwhelmingly match the open-source Tor codebase**: hundreds of message strings reference Tor concepts (HiddenServiceNonAnonymousMode, EntryNodes, UseEntryGuards, "Onion services v2 are now obsolete...", "Bridges are not loaded", consensus URLs, etc.) — these come straight from the Tor source tree.
3. **Imports** are standard for a network/crypto daemon: ws2_32 (sockets), advapi32 (CryptAcquireContext / CryptGenRandom), iphlpapi, kernel32 fiber APIs (Tor uses fibers for its event loop on Windows). No `WriteProcessMemory`, no `CreateRemoteThread`, no clipboard or browser-credential APIs, no LSASS-related calls, no PEB walking, no HTTP downloader strings other than legitimate directory protocol.
4. **No sub-files / virtual files** were present. The binary is self-contained.
5. **CreateService Yara hit** at ea 7315074 is reachable from a function near the `--service` CLI handler (refs at sub_1400bf940 referencing the `--service` string at ea 7314564). This is Tor's documented Windows-service install flag, not a persistence trojan.
6. **No Kesakode verdict** was returned (clean / unknown to threat intel).

## Sub-files

None. The file does not contain embedded resources, archives, or carved files relevant to analysis.

## Counter-arguments / Shortcomings

- The binary uses Tor, which is in itself often abused by malware (ransomware, droppers, C2 over .onion). However, **this file is the Tor daemon itself**, not a tool that *embeds* Tor for malicious purposes. Malware that uses Tor typically drops/ships this binary alongside its real payload — but in isolation, `tor.exe` is benign.
- The PE has `TimeDateStamp = 0` and no checksum: this is normal for MinGW builds (GCC linker `-Wl,--no-insert-timestamp` is explicitly visible in the compiler banner) and is a deliberate reproducibility setting from the Tor Project, not a malware tell.
- Whether this exact binary is the official signed distribution from torproject.org cannot be confirmed from static analysis alone (the file is unsigned, as is the canonical mingw-built `tor.exe` from the Tor Browser bundle / Expert Bundle). A hash comparison against the Tor Project's published artifacts would be required for full provenance, but no signs of tampering, code-cave injection, or appended payloads were observed.

## Verdict

**CLEAN — Legitimate Tor 0.4.8.12 daemon for Windows x64.**

**Confidence: ~95% benign.**

Recommendation: treat as a dual-use networking tool. If found on an endpoint without IT/user justification, escalate as policy-violation (anonymizing proxy) or possible companion file to a malware family that ships Tor to reach onion C2 — but the file itself is not malicious.