TI-2026-019M โ "The Researcher" โ Max-Planck-Institut fรผr Informatik: When State-Funded Science Scans Your Infrastructure Through Tor While Claiming It Doesn't
๐ฌ Executive Summary
Our honeypot captured a sophisticated, multi-phase operation originating from Max-Planck-Institut fรผr Informatik (MPI-INF), Saarbrรผcken, Germany โ one of the world's most prestigious computer science research institutions, fully funded by the German federal and state governments (โฌ2.4 billion/year total Max Planck budget).
The operation involves 14 disclosed scanning servers, global AWS vantage points across 10+ regions, and โ critically โ undisclosed Tor-routed operations that directly contradict their own public ethics statement.
โ ๏ธ THE CONTRADICTION: MPI-INF's official disclosure page states: "We never attempt to abuse security vulnerabilities on your system, guess for passwords or upload files to your systems."
Our forensic evidence proves they log in with root:root and admin:admin through Tor exits, execute environment detection commands, and use session tracking IDs โ all while anonymized through Church of Cyberology (DOSSIER-019L) infrastructure.
โ๏ธ This dossier presents two perspectives: the charitable interpretation and the investigative counter-perspective. Both are supported by evidence. The contradiction between disclosure and behavior is factual, not speculative.
๐ Section 1: The Evidence Matrix
1.1 โ The Disclosed Infrastructure (from their own page)
Source: http://inet-research-scan-5.mpi-inf.mpg.de/ (official disclosure page)
| Category | Infrastructure | Count |
|---|---|---|
| On-campus scanners | inet-research-scan-{1-14}.mpi-inf.mpg.de | 14 servers |
| AWS "Looking Glass" probes | inet-lg-p-*.dyn.mpi-klsb.mpg.de (Sydney, Stockholm, Bahrain, Singapore, HK, Virginia, Sรฃo Paulo, California, Frankfurt, Tokyo) | 10 regions |
| AWS "GeoCache" probes | inet-gc-p-*.dyn.mpi-klsb.mpg.de (Frankfurt, Stockholm, Virginia, California, Mumbai, Sรฃo Paulo) | 6 regions |
| Total disclosed infrastructure | 14 dedicated servers + 16 cloud VMs | 30 nodes minimum |
Note: Only scan-5 (139.19.117.129) appears in our honeypot data. None of the other 29 disclosed nodes have contacted us. This is either targeting or coincidence.
1.2 โ The Undisclosed Operation (Tor-routed, not on their page)
| Attribute | Phase 1 (Passive) | Phase 2 (Active) |
|---|---|---|
| Period | March 28 โ June 6, 2026 | May 5 โ May 11, 2026 |
| Client | SSH-2.0-OpenSSH_9.9 | SSH-2.0-OpenSSH_9.9 + SSH-2.0-Go |
| Credentials | root:root | admin:admin |
| Login success | Yes (honeypot accepted) | Yes (honeypot accepted) |
| Commands executed | 0 (login + idle 20-25s) | 3 per session (honeypot fingerprinting) |
| Session duration | 20-25 seconds | 7-10 seconds |
| SSH key leaked | d4:98:c4:f3:... | d4:98:c4:f3:... + sessions without key |
| Exits used | 15 Cyberology + 1 MOJI SAS | 4 Cyberology exits |
| Disclosed? | NO | NO |
๐จ Section 2: The Smoking Gun โ Commands Executed Through Tor
On 4 dates in May 2026, the Tor-routed operation escalated from passive (login-only) to active honeypot fingerprinting:
This command chain performs four distinct fingerprinting operations:
| Command | Purpose | What it reveals |
|---|---|---|
bash --help | Shell capability detection | Real bash vs. busybox vs. honeypot fake shell |
ls /proc/1/ | PID 1 process inspection | Init system = real server; limited PID 1 = container/honeypot |
cat /proc/1/mounts | Mount point enumeration | Docker overlayfs = container; tmpfs = honeypot; real mounts = bare metal |
cat /proc/cpuinfo | Hardware fingerprint | Real CPU model = physical server; generic = VM; truncated = honeypot |
echo __<number> | Session correlation ID | Go time.Now().UnixNano() โ allows matching Tor sessions across exits |
Tracking ID Verification:
| Tracking ID | Decoded Timestamp | Actual Session Time | Delta |
|---|---|---|---|
1777998079878558612 | 2026-05-05 16:21:19 UTC | 2026-05-05 16:21:20 UTC | 1 second |
1778088221198072728 | 2026-05-06 17:23:41 UTC | 2026-05-06 17:23:41 UTC | 0 seconds |
1778169198294820594 | 2026-05-07 15:53:18 UTC | 2026-05-07 15:53:18 UTC | 0 seconds |
1778496376103600599 | 2026-05-11 10:46:16 UTC | 2026-05-11 10:46:16 UTC | 0 seconds |
Analysis: The tracking IDs are Go time.Now().Unix() timestamps generated at the source (before Tor latency). The exact match between decoded ID and session timestamp proves the commands were generated in real-time by a Go application โ matching MPI's known use of Go-based scanners (SSH-2.0-Go on their direct scans).
๐ Section 3: The Complete Operation Timeline
33 active days across 3 modes of operation:
Key observation: Phase 2 (active honeypot detection) lasted exactly 7 days (May 5-11), then stopped. This is consistent with either: (a) a specific experiment that concluded, or (b) a campaign that achieved its objective.
๐ Section 4: The Three Scanner Identities
We have definitively identified three distinct scanning tools used by this operation:
| Tool | HASSH | Client | SSH Key | Where Used | Behavior |
|---|---|---|---|---|---|
| Scanner A | f1e5e9d2... | SSH-2.0-Go | d4:98:c4:f3:... | Direct only (scan-5) | Handshake-only, no credentials |
| Scanner B | 1cc79c7d... | SSH-2.0-OpenSSH_9.9 | d4:98:c4:f3:... | Tor exits only | root:root login, sometimes admin:admin + commands |
| Scanner C | 087ab61d... | SSH-2.0-Go | not captured | Tor exits only | admin:admin + commands (same pattern) |
Linking evidence:
- Scanners A and B share SSH key
d4:98:c4:f3:...โ same operator - Scanners B and C appear on the same exit IP on the same day (e.g., 192.42.116.16 on May 5) โ same operator, different tools
- Scanners B and C execute the identical command pattern with Go-style tracking IDs โ same codebase
- Scanner A uses Go, Scanner C uses Go, tracking IDs are Go timestamps โ unified Go application
Conclusion: All three are different modes of a single application. Scanner A (HASSH f1e5e9d2) is the direct-scan mode. Scanner B wraps it in OpenSSH via Tor. Scanner C is a separate Go binary for the active/command phase.
โ PERSPECTIVE 1 โ The Charitable Academic Interpretation
Assessment: This is internet measurement research that includes honeypot detection as part of its methodology. The "password guessing" is actually testing whether hosts respond differently to authentication attempts โ distinguishing honeypots from real servers.
Arguments supporting this interpretation:
- Disclosure page exists: They self-identify, offer opt-out, cite ethics guidelines (Menlo Report, Partridge & Allman 2016)
- Zero exploitation: Even in Phase 2, commands only collect system information โ no malware, no persistence, no data exfiltration
- Published researchers: Dr. Johannes Zirngibl ("Large scale analysis & Internet measurements"), Dr. Tiago Heinrich ("Intrusion Detection, Computer and Network Security") โ both on the INET department page
- Honeypot research is legitimate: Detecting honeypots is a valid research topic (how effective are deception technologies?)
- The disclosure gap might be intentional: If they disclosed "we test passwords to detect honeypots," honeypot operators would adapt, invalidating the research
- Phase 2 was brief (7 days): Consistent with a specific experiment, not ongoing exploitation
- The tracking IDs prove scientific rigor: They're correlating sessions across Tor exits for measurement consistency โ not malicious tracking
- OMEGATECH uses similar commands but WITH exploitation: MPI's version is read-only, OMEGATECH's includes write operations and crypto miners
Probable research questions:
- What percentage of internet-facing SSH servers are actually honeypots?
- Can honeypots be reliably detected from an unauthenticated connection? What about authenticated?
- Do honeypots respond differently to Tor vs. direct connections?
- How many "attack" reports in threat feeds are actually honeypot artifacts?
The charitable reading of the disclosure contradiction: Their page says "We never attempt to guess for passwords" โ using root:root isn't "guessing," it's testing the most common default credential to see how systems respond. Semantic distinction? Perhaps. But academics have published papers with this exact framing.
โ PERSPECTIVE 2 โ The Investigative Counter-Analysis
These are the questions any intelligence analyst, journalist, or cybersecurity investigator is trained and obligated to ask. The answers to these questions determine whether this is science or something else.
๐ Q1: Why use Tor if you're doing legitimate research?
Their likely answer: To test if hosts respond differently to Tor traffic vs. direct traffic.
The problem with that answer: They have 30 disclosed scanning nodes across 16 geographic regions including AWS IPs in 10 countries. They could compare responses from Germany vs. Singapore vs. Brazil vs. Virginia without Tor. They CHOSE Tor specifically because it provides anonymity, not just geographic diversity.
What the data says: Their direct scans (Scanner A) use NO credentials and do NO exploitation. Their Tor scans (Scanners B/C) use credentials AND execute commands. The anonymity layer correlates with the aggression level. This is not accidental.
๐ Q2: Why does the disclosure page lie?
The quote: "We never attempt to abuse security vulnerabilities on your system, guess for passwords or upload files to your systems."
The evidence: root:root (19 sessions), admin:admin (3 sessions with command execution). These are passwords. They were used to authenticate. The honeypot accepted them.
Possible explanations:
- (a) The Tor operation is conducted by different people than those who wrote the disclosure โ compartmentalization
- (b) The disclosure was written for the direct scans only; the Tor operation is deliberately not covered โ selective disclosure
- (c) They don't consider
root:root"guessing" because it's a known default โ semantic evasion - (d) The Tor operation is not authorized by the institution โ rogue researcher or separate funding source
What we can verify: The same SSH key (d4:98:c4:f3:...) links the disclosed direct scanner to the undisclosed Tor scanner. Same operator, same key material. Either the institution knows or its security is compromised.
๐ Q3: Who funds this and what do they receive?
Known facts:
- Max Planck Society receives โฌ2.4 billion/year from German federal (50%) and state (50%) governments
- The INET department's research areas explicitly include "Internet measurement" and "Network Security"
- The German government's BND reform (2016) expanded signals intelligence authority
- Germany participates in the "14 Eyes" intelligence alliance
- MPI-INF has documented collaborations with German government agencies
What we cannot verify: Whether the scanning dataset is shared with BND/BSI, whether EU-funded projects (Horizon Europe) require data sharing with security agencies, whether classified side-agreements exist.
What the disclosure page carefully avoids: It says they "will try to publish all our findings to a wider audience" and will never publish data that "clearly identifies you." It does NOT say who else receives the RAW data. "Publishing" and "sharing" are different verbs.
๐ Q4: Is this honeypot detection... or honeypot MAPPING?
The distinction matters:
- "Detection" (research): Can honeypots be identified? Result โ academic paper
- "Mapping" (intelligence): WHERE are honeypots? Result โ operational database for avoiding them
What the commands reveal: /proc/1/mounts + /proc/cpuinfo + bash --help = a binary classifier: "is this target real or fake?" The tracking IDs allow correlating results across sessions. An internet-wide scan with this classifier produces a global map of deception infrastructure.
Who would want a honeypot map?
- Attackers โ to avoid detection when deploying actual exploits
- Intelligence agencies โ to know which networks deploy deception (= who is security-aware)
- Researchers โ to quantify honeypot deployment for a paper
All three users benefit from the same dataset. The intent is indistinguishable from the data alone.
๐ Q5: Why evening timing? Why human-scheduled?
Data: Tor scans cluster 18:00-21:00 UTC (19:00-22:00 CET = German evening). Direct scans are distributed 01:00-23:00 (automated).
Research interpretation: A PhD student runs the Tor experiments manually as part of their daily routine.
Counter-interpretation: After-hours operation avoids institutional oversight. IT departments don't monitor traffic at 9pm. The direct scans are automated (cron job = institutional); the Tor scans are manual (human = personal/deniable).
The Friday pattern: 9 of 15 direct scan sessions occurred on Fridays. Either the researcher likes Fridays, or batch jobs run on end-of-week schedules.
๐ Q6: What does it mean that MPI shares a threat feed with Russian bulletproof hosting?
Data: OTX pulse 69e1ede7... (cluster of 6 IPs) contains BOTH MPI (139.19.117.129) AND FORTIS-AS (45.144.233.139 โ Baykov Ilya Sergeevich, Russia, 6,795 abuse reports).
Research interpretation: Threat feeds aggregate scanners indiscriminately. MPI scans the internet; so do botnets. Both end up in the same "malicious scanners" lists. This is a false positive.
Counter-interpretation: Being categorized alongside Russian bulletproof hosters in a 6-IP cluster means their scanning BEHAVIOR is indistinguishable from actual threats. If the 4,612 AbuseIPDB reporters and OTX pulse curators cannot tell the difference, why should we?
๐ Q7: The SSH key paradox โ deliberate or negligent?
Data: SSH key d4:98:c4:f3:... is used both from a named institutional IP AND through Tor exits. This perfectly deanonymizes them.
If deliberate: The key serves as a "flag" to anyone monitoring Tor exits who has MPI's key on file. It says "this is us, not a criminal" โ a deconfliction mechanism. NATO/5-Eyes partners with access to this key would know not to investigate further.
If negligent: A world-class computer science institution studying network security failed to generate a separate key for their anonymized scanning. This would be a remarkable oversight for experts in this exact field.
If research-intentional: They're deliberately testing whether honeypots correlate keys across connections (testing OUR detection capability). By reusing the key, they learn which targets can deanonymize Tor users.
All three are concerning for different reasons.
๐ Q8: 4,612 abuse reports โ why no institutional response?
Data: AbuseIPDB confidence: 100%. Reports: 4,612. No public acknowledgment or statement from MPI-INF about these reports.
Research interpretation: The disclosure page IS their response. Anyone who looks up the IP finds the page. They don't respond to individual reports because there are too many.
Counter-interpretation: 4,612 organizations reported being scanned without consent. The Menlo Report (cited on their OWN disclosure page) requires "beneficence" and "respect for persons." Scanning without active consent and ignoring 4,612 complaints is a debatable interpretation of these principles.
The practical question: Would YOU accept this behavior from a Russian, Chinese, or Iranian institution? If not, why is German state-funded scanning acceptable?
โ๏ธ Section 5: The Analytical Verdict
- Official disclosure page exists โ
- Named researchers with publication history โ
- Zero exploitation or persistence โ
- Read-only commands (no writes) โ
- Academic network (DFN) โ
- Consistent with honeypot research โ
- Phase 2 was time-limited (7 days) โ
- Opt-out mechanism offered โ
- Disclosure explicitly denies password guessing โ
- Evidence proves password use through Tor โ
- Tor provides anonymity for the aggressive phase โ
- Commands identical to known malicious recon โ
- Evening/manual timing pattern โ
- State-funded with no data-sharing disclosure โ
- 4,612 reports with no institutional response โ
- SSH key reuse = opsec failure or deliberate signal โ
The direct scanning (Scanner A) is clearly legitimate research โ handshake-only, self-identified, disclosed. We have no dispute with this.
The Tor-routed operation (Scanners B/C) exists in a grey zone that their disclosure does not cover and their ethics statement explicitly contradicts. Whether this is:
- (a) A separate experiment with different ethics approval
- (b) A parallel operation with different stakeholders
- (c) A rogue researcher exceeding authorized scope
- (d) An intelligence operation under academic cover
...cannot be determined from network forensics alone. What CAN be determined: they said they don't guess passwords. They do. Through Tor. While fingerprinting honeypots. The evidence speaks for itself.
๐ Section 6: Technical Attribution Chain
๐ง Section 7: What This Proves About Our Methodology
The d4:98:c4:f3 key appeared on 16 different Tor exits + 1 direct IP. If MPI were a criminal, we achieved complete deanonymization with zero uncertainty. Tor protects IP identity; it does not protect SSH key identity.
Three distinct HASSH values = three modes of the same tool. Even without the SSH key, the identical commands + Go timestamps + shared exit IPs would link them with high confidence.
The Go timestamps in the commands are generated at the SOURCE, before Tor latency. They prove the operator's clock is synchronized (NTP) and the application generates IDs in real-time โ not from a pre-built command list.
The transition from passive (Phase 1: root:root, no commands, 20-25s) to active (Phase 2: admin:admin, 3 commands, 7-10s) on May 5 shows a deliberate escalation. The operator first established baseline access patterns, then introduced detection commands once comfortable the targets wouldn't alert.
MPI has a disclosure page. It cites ethics guidelines. It offers opt-out. By every standard metric, they are "responsible." Yet their actual behavior contradicts their stated limitations. A disclosure page is not an ethics audit. Self-regulation without external verification is just reputation management.
๐ Section 8: Unanswered Questions (Active Investigation)
These require information beyond what network forensics can provide:
- Has this Tor-routed scanning been approved by MPI-INF's ethics board? (Contact:
inet-scans@mpi-inf.mpg.de) - Which specific research project funds this work? Is there EU/German government co-funding with data-sharing requirements?
- Does the scanning dataset feed into any classified or restricted-access system?
- Was the 7-day Phase 2 (May 5-11) pre-approved, or was it a researcher acting beyond scope?
- Why do only 4 of the 14 disclosed scanners appear active? Are the others conducting undiscovered operations?
- Who are the "wider audience" receiving publications, and do they also receive raw data?
- Has the German Federal Commissioner for Data Protection been notified about internet-wide SSH credential testing?
- Does this operation have a corresponding entry in the DFN-CERT incident registry?
๐๏ธ Section 9: Historical Context โ Why These Questions Must Be Asked
The history of state-funded institutions conducting undisclosed operations is not conspiracy theory. It is documented fact:
- NSA/GCHQ (2013, Snowden): University partnerships used for signals intelligence research. Academic papers published from classified datasets.
- CIA MKUltra (1953-1973): 44 American universities participated in classified experiments. Researchers published "civilian" papers from the same work.
- BND/German Intelligence (2020): German Constitutional Court ruled BND's foreign telecommunications surveillance partially unconstitutional
- PRISM (2013): Tech companies provided data to intelligence agencies while maintaining public privacy policies that said otherwise
- Dual EC DRBG (2013): NIST standard revealed to contain NSA backdoor. The standard was "legitimate research" until it wasn't.
The pattern: Legitimate research institutions produce legitimate research. Sometimes, concurrently, the same data flows elsewhere. The researchers may or may not know. The institution may or may not authorize it. The disclosure page says what the disclosure page says. The network packets tell a different story.
Our position: We don't know if this is the case here. We report what we observe. What we observe contradicts what they claim. Beyond that, we can only ask questions.