<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
     xmlns:dc="http://purl.org/dc/elements/1.1/"
     xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
     xmlns:admin="http://webns.net/mvcb/"
     xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
     xmlns:content="http://purl.org/rss/1.0/modules/content/"
     xmlns:media="http://search.yahoo.com/mrss/">
<channel>
    <title>Cybersecurity Tomorrow &amp; : Infosec Writeups (Medium)</title>
    <link>https://cybersecuritytomorrow.com/rss/category/infosec-writeups-medium</link>
    <description>Cybersecurity Tomorrow &amp; : Infosec Writeups (Medium)</description>
    <dc:language>en</dc:language>
    <dc:creator></dc:creator>
    <dc:rights>Copyright 2025 Cybersecurity Tomorrow &amp; All Rights Reserved.</dc:rights>
    <item>
        <title>Infrastructure Pivoting: How CTI Analysts Expand From a Single IOC to a Full Attacker Network</title>
        <link>https://cybersecuritytomorrow.com/infrastructure-pivoting-how-cti-analysts-expand-from-a-single-ioc-to-a-full-attacker-network</link>
        <guid>https://cybersecuritytomorrow.com/infrastructure-pivoting-how-cti-analysts-expand-from-a-single-ioc-to-a-full-attacker-network</guid>
        <description><![CDATA[ The field manual for tracing attacker infrastructure — from one domain to dozensContinue reading on InfoSec Write-ups » ]]></description>
        <enclosure url="http://cdn-images-1.medium.com/max/2600/1*1ehWz4-YEZTo-PXo4FwemA.png" length="49398" type="image/jpeg"/>
        <pubDate>Sun, 22 Mar 2026 15:40:54 -0400</pubDate>
        <dc:creator>Darpan Neupane</dc:creator>
        <media:keywords>Infrastructure, Pivoting:, How, CTI, Analysts, Expand, From, Single, IOC, Full, Attacker, Network</media:keywords>
    </item>
    <item>
        <title>Ploutus Malware: Uptick in ATM jackpotting incidents prompts FBI warning</title>
        <link>https://cybersecuritytomorrow.com/ploutus-malware-uptick-in-atm-jackpotting-incidents-prompts-fbi-warning</link>
        <guid>https://cybersecuritytomorrow.com/ploutus-malware-uptick-in-atm-jackpotting-incidents-prompts-fbi-warning</guid>
        <description><![CDATA[ Three weeks ago, renewed activity involving Ploutus ATM malware surfaced, prompting an alert from the Federal Bureau of Investigation (FBI). At the time, we published an initial breakdown covering the threat and its implications for financial institutions — an analysis that was later recognized as a Top Perspective on LinkedIn, reflecting the growing industry concern around ATM-targeted attacks.Uptick in ATM jackpotting incidents prompts FBI warning | LinkedInThe recent warning has since reignited discussions across financial security circles. But beyond the headlines, a more important question emerges:Why are ATMs still vulnerable to jackpotting in 2026 — and what actually works to stop it?ATM attacks are no longer about fraud. They are about direct cash extraction via system-level manipulation.Ploutus enables attackers to bypass:Card authenticationBanking systemsTransaction validationAnd directly command the ATM to dispense cash.This follow-up article goes beyond surface-level analysis — delivering a deep technical breakdown of how these attacks work, why they continue to succeed, and what actually stops them in real-world environments.ATM Architecture: Why Jackpotting Is PossibleModern ATMs are not simple machines — they are specialized endpoints.Typical characteristics:Windows Embedded / IoT operating systemsXFS (Extensions for Financial Services) middlewareLimited CPU, memory, and storageOften network-isolated or semi-isolatedMaintained by third-party vendorsThe Critical Layer: XFS MiddlewareXFS acts as the bridge between software and hardware:Cash dispenserCard readerPIN padReceipt printerPloutus targets this layer directly.Instead of attacking banking systems, it speaks the ATM’s native language. Once XFS is compromised, the attacker can issue dispense commands without any transaction validation.Ploutus Attack Chain (End-to-End)Phase 1: Initial AccessMost real-world attacks begin with physical compromise:ATM cabinet openedUSB payload insertedBoot process manipulatedAdministrative access obtainedLess frequently:Network pivot via weak segmentationPhase 2: Malware DeploymentThe payload:Injects into ATM processesHooks XFS APIsDisables protectionsMay establish persistenceAdvanced capabilities:ObfuscationVendor-specific targetingEncrypted triggersLog manipulationPhase 3: ExecutionAttackers trigger the malware via:Keypad sequencesExternal input devicesTime-based triggersThe ATM:Executes rapid dispense commandsBypasses transaction flowOperates without card interactionPhase 4: Cash-OutRapid cassette emptying$20K–$200K loss per machineOperation completed within minutesThe Real Issue: Not Advanced — Just UncontrolledDespite its reputation, Ploutus often succeeds due to basic failures:No full-disk encryptionShared or weak credentialsUSB ports left exposedDisabled or ignored alarmsPoor physical securityThis aligns with industry feedback:“Nothing super high-tech — just basics that shouldn’t exist.”Attackers don’t need zero-days. They need gaps in enforcement.Why Traditional Anti-Malware Fails in ATMsATM environments impose constraints:Network isolation limits cloud-based detectionPCI compliance restricts architectureLow hardware resources limit EDR deploymentPatch cycles are slowFrom the AppGuard case study:ATMs are “network isolated &amp; low-power”, making traditional detection-heavy tools impractical .This creates a mismatch:Detection tools expect connectivity and resourcesATMs provide neitherDetection vs Prevention: The Industry DivideDetection-Based ApproachesSignature AVMachine learning AVEDR / behavioral analyticsChallenges:Alert fatigueRequires human triageDelayed responsePrevention-Based ApproachesApplication whitelistingZero-trust execution controlAdvantages:Blocks unknown binariesMinimal overheadWorks offlineAdvanced Detection Engineering (Multi-Layer Model)Effective detection requires correlation across three layers:OS-Level DetectionKey telemetry:Event ID 4688 → Process creationEvent ID 7045 → Service installEvent ID 1102 → Log clearingSysmon Event ID 1Indicators:Execution from USB pathsUnknown binariesSuspicious parent-child chainsUSB &amp; Physical Interaction MonitoringKernel-PnP logsDevice insertion anomaliesActivity outside maintenance windowsXFS Middleware MonitoringMonitor:DLL injection into ATM processesUnauthorized module loadingAPI hooking behaviorDispense Behavior Detection (Most Reliable)Normal:One dispense per transactionMalicious:Rapid repeated dispensesNo card interactionRule: IFMultiple dispense events ANDNo card/PIN validation → Trigger lock immediatelyCash Dispenser TelemetryCorrelate:High dispense volumeNull transaction IDsAfter-hours activityDetection must happen locally and instantly.Sigma-Style Detection RulesSuspicious USB ExecutionProcess from removable mediaAND not signed by trusted vendor→ AlertLog ClearingEventID = 1102→ High severity alertAbnormal Dispensedispense_count &gt; thresholdAND transaction == null→ Critical alert + auto lockXFS InjectionUnknown DLL in ATM process→ Block / Al ]]></description>
        <enclosure url="http://cdn-images-1.medium.com/max/1024/1*Fzglouir4yQlVAVsrBL-dw.png" length="49398" type="image/jpeg"/>
        <pubDate>Sun, 22 Mar 2026 15:40:54 -0400</pubDate>
        <dc:creator>Darpan Neupane</dc:creator>
        <media:keywords>Ploutus, Malware:, Uptick, ATM, jackpotting, incidents, prompts, FBI, warning</media:keywords>
    </item>
    <item>
        <title>How I Found a Hardcoded RSA Private Key in a Major Crypto Exchange’s Frontend</title>
        <link>https://cybersecuritytomorrow.com/how-i-found-a-hardcoded-rsa-private-key-in-a-major-crypto-exchanges-frontend</link>
        <guid>https://cybersecuritytomorrow.com/how-i-found-a-hardcoded-rsa-private-key-in-a-major-crypto-exchanges-frontend</guid>
        <description><![CDATA[ How I Found a Hardcoded RSA Private Key in a Major Crypto Exchange’s Frontend -And What I Learned the Hard WayA Bug Bounty Story About Recon, Excitement, and Harsh RealityIt started like any other Saturday morning. Coffee in hand, terminal open, and a fresh bug bounty target loaded up. What followed was one of the most educational experiences of my security research career — not because I earned a massive bounty, but because I didn’t.This is that story.The TargetI was hunting on a major cryptocurrency trading platform’s bug bounty program. The scope was broad — *.target.com, iOS app, Android app — and the rewards were listed as Critical bounty for serious findings. The in-scope vulnerability list included the good stuff: SSRF, Business Logic, RCE, Access Control issues, Sensitive Information Disclosure.I decided to start with what I call passive JavaScript recon — one of the most underrated techniques in web bug bounty.Phase 1: JavaScript Recon (Where the Gold Hides)Most hunters jump straight to fuzzing endpoints or running automated scanners. I’ve learned that the real treasure is often hiding in plain sight — inside the frontend JavaScript bundles that ship directly to your browser.# Download the main app bundlecurl -s https://static.target.com/web-frontend/client/app.xxxxx.js -o app.js# Search for interesting keywordsgrep -iE &#039;private_key|secret|password|api_key|token&#039; app.jsAnd then it happened.TRACK_PRIVATE_KEY: &quot;MIICdQIBADANBgkqhkiG9w0BAQEFAA...&quot;My coffee went cold. I was looking at what appeared to be a complete RSA private key hardcoded inside a production JavaScript file — publicly accessible to anyone who visited the website.My heart was racing.Phase 2: Validation — Is This Real?First rule of bug bounty: don’t get excited until you validate. I extracted the key and ran it through OpenSSL immediately.# Save and validate the keycat &gt; extracted.key  ]]></description>
        <enclosure url="http://cdn-images-1.medium.com/max/1024/1*HJzbF9UcCe9yLUb7dWSWyA.png" length="49398" type="image/jpeg"/>
        <pubDate>Sun, 22 Mar 2026 15:40:54 -0400</pubDate>
        <dc:creator>Darpan Neupane</dc:creator>
        <media:keywords>How, Found, Hardcoded, RSA, Private, Key, Major, Crypto, Exchange’s, Frontend</media:keywords>
    </item>
    <item>
        <title>Found a Denial of Service Vulnerability in a Major Company’s Production Infrastructure Using Shodan</title>
        <link>https://cybersecuritytomorrow.com/found-a-denial-of-service-vulnerability-in-a-major-companys-production-infrastructure-using-shodan</link>
        <guid>https://cybersecuritytomorrow.com/found-a-denial-of-service-vulnerability-in-a-major-companys-production-infrastructure-using-shodan</guid>
        <description><![CDATA[ A step-by-step story of reconnaissance, discovery, and responsible disclosureBug bounty hunting is rarely glamorous. Most of the time, it’s hours of staring at HTTP responses, chasing dead ends, and questioning whether that “weird behavior” is actually a vulnerability or just… intended. This is the story of one of those hunts — where a simple Shodan search led me down a rabbit hole that ended with a legitimate Denial of Service vulnerability on production infrastructure serving millions of users.The Hunt Begins: Shodan ReconnaissanceEvery good bug hunt starts with reconnaissance. My target was a large tech company with a public bug bounty program that included IP ranges in their scope. This is often an overlooked attack surface — most researchers focus on web applications and APIs, ignoring raw IP ranges entirely.I fired up Shodan and searched their IP range:net:185.26.x.x/22Most results were boring — a few nginx servers returning 301 redirects, some DNS servers. Standard stuff. But one IP caught my eye immediately.The Interesting HostOne particular host stood out from the rest. While other servers in the range were running standard nginx, this one was running something completely different:Server: Pike v8.0 release 908: HTTP Server modulePike HTTP Server. Not something you see every day.More interesting was the port list:Open Ports: 22, 80, 123, 1080, 2049, 2345, 8081, 8192, 8888, 8889, 9000Eleven open ports on a production server. Each one a potential story.My eyes immediately went to three unusual ports:Port 2049 — traditionally NFS (Network File System)Port 1080 — traditionally SOCKS proxyPort 2345 — traditionally DBM (Database Manager)Ports 8888/8889 — unknown Pike servicesThis was not a standard web server. This was infrastructure.Peeling Back the LayersNFS on Port 2049?My first instinct was to enumerate the NFS service:showmount -e [TARGET_IP]# Result: clnt_create: RPC: Unable to receiveInteresting. The port was open but RPC wasn’t responding. I ran a more detailed nmap scan:nmap -sV -p 111,2049 --script=rpcinfo [TARGET_IP]The result was surprising. Port 2049 wasn’t NFS at all. It was responding with something completely custom:_version\xa0\xe8\xa3\x06\x15cmbt9x79skf8qsbx8hr8q25xgA custom binary protocol, disguised on the NFS port. Every request returned a different random session identifier. This was Opera’s internal proprietary protocol hiding in plain sight on a well-known port — security through obscurity.Port 1080: Closed SOCKScurl --socks5 [TARGET_IP]:1080 http://example.com# Result: curl: (97) connection to proxy closedNot an open proxy. Connection immediately refused. Moving on.Port 8888: Where Things Got InterestingThis is where the real story begins.A simple GET request to port 8888:curl http://[TARGET_IP]:8888/Response:HTTP/1.1 400 Bad RequestServer: Pike v8.0 release 908: HTTP Server moduleDon&#039;t know how to handle request in ext.Immediately interesting. “ext” — an internal Pike module. The server is telling me it has an extension module but doesn’t know how to handle my request. What happens with other HTTP methods?curl -X PUT http://[TARGET_IP]:8888/# Response: &quot;Unhandled method in ext&quot;curl -X DELETE http://[TARGET_IP]:8888/# Response: &quot;Unhandled method in ext&quot;Different error messages for different methods. The server is clearly processing requests through an “ext” module handler. But what about POST?curl -X POST -d &quot;test&quot; http://[TARGET_IP]:8888/I stared at my terminal.Nothing happened.The cursor just… blinked.The Vulnerability Reveals ItselfI waited. Five seconds. Ten seconds. Thirty seconds. A minute.No response.In my experience, this behavior — connection established, data sent, server silent — is almost always significant. Normal servers always respond, even if it’s just an error code. Silence is not normal.I opened a second terminal and ran netstat monitoring:watch -n 2 &quot;netstat -tn | grep [TARGET_IP]:8888&quot;Then sent the POST request again. The netstat output showed:tcp    0    0  MY_IP:44334    TARGET_IP:8888    ESTABLISHEDThe connection was in ESTABLISHED state. The server had accepted my connection, received my data, and… stopped. No response. No timeout. Just open, consuming resources, indefinitely.I set a 300-second timeout to measure exactly how long the server would hold the connection:timeout 300 curl -X POST -d &quot;test&quot; http://[TARGET_IP]:8888/echo $?After exactly 300 seconds, my terminal returned:124Exit code 124. The timeout command killed the process because the server never responded in 300 seconds.This was not normal behavior. This was a vulnerability.Understanding the BugLet me explain what was actually happening technically.When you send an HTTP POST request to a normal server, the following happens:Client → Server: TCP SYNServer → Client: TCP SYN-ACKClient → Server: TCP ACK (handshake complete)Client → Server: HTTP POST dataServer → Client: HTTP Response (200, 400, 500, anything)Connection closes.On this server:Client → Server: TCP SYN ✅Server → Client: TCP SYN-ACK ✅C ]]></description>
        <enclosure url="http://cdn-images-1.medium.com/max/1024/1*zKCBRuXVN524KPSGDjvReg.png" length="49398" type="image/jpeg"/>
        <pubDate>Sun, 22 Mar 2026 15:40:54 -0400</pubDate>
        <dc:creator>Darpan Neupane</dc:creator>
        <media:keywords>Found, Denial, Service, Vulnerability, Major, Company’s, Production, Infrastructure, Using, Shodan</media:keywords>
    </item>
    <item>
        <title>TraceBack Box Writeup From HTB DOT EU</title>
        <link>https://cybersecuritytomorrow.com/traceback-box-writeup-from-htb-dot-eu</link>
        <guid>https://cybersecuritytomorrow.com/traceback-box-writeup-from-htb-dot-eu</guid>
        <description><![CDATA[ Looking at the box on HTB rating and graph levels , it looks more of a CTF — Like Box so lets try to crack it :PLets head to start with INFOGATHER as always.1st of Every Penetration Session.INFO GATHERINGstarting with nmap scan as following :sudo nmap -sC -sV -oA nmap/traceback 10.10.10.181two ports are open from the results 22 SSH 80 APACHEThe nmap results are as follows :PORT STATE SERVICE VERSION22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)| ssh-hostkey: | 2048 96:25:51:8e:6c:83:07:48:ce:11:4b:1f:e5:6d:8a:28 (RSA)| 256 54:bd:46:71:14:bd:b2:42:a1:b6:b0:2d:94:14:3b:0d (ECDSA)|_ 256 4d:c3:f8:52:b8:85:ec:9c:3e:4d:57:2c:4a:82:fd:86 (ED25519)80/tcp open http Apache httpd 2.4.29 ((Ubuntu))|_http-server-header: Apache/2.4.29 (Ubuntu)|_http-title: Help usService Info: OS: Linux; CPE: cpe:/o:linux:linux_kernelService detection performed. Please report any incorrect results at https://nmap.org/submit/ .Nmap done: 1 IP address (1 host up) scanned in 36.74 seconds```lets try all flag , “all ports” maybe we are missing some ports that are open. Just in case.lets while that is running enumerate the web directory and check the index and headers , etc.looking at the main page we find a scary message :lets see if enumeration work in the next part of this writeup.all ports flag also gave us the same results so no need for it actually2nd Vital Step of Penetration Session is :ENUMERATION AND SCANNINGLets enumerate with dirb this time just because it’s easy.dirb http://10.10.10.181or sudo dirb http://10.10.10.181 -o /home/MrRobot/Documents/Documents/BoxesHACK/Traceback/resultsenumeration.txtlets wait while we wait lets run some tools```dig 10.10.10.181curl 10.10.10.181nothing special.lets move forward  with enumeration results we get two directories  Scanning URL: http://10.10.10.181/ — — + http://10.10.10.181/index.html (CODE:200|SIZE:1113) + http://10.10.10.181/server-status (CODE:403|SIZE:300)nothing special about these results lets try another wordlist ..Lets Scan &gt;&gt;dirb http://10.10.10.181/ /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -o /home/MrRobot/Documents/Documents/BoxesHACK/Traceback/resultsenumLets google the apache ubuntu version.Apache httpd 2.4.29 ((Ubuntu))going back to something i noticed in the source page or the main page lets mention itthere was writting something that gave us a clue about what we are dealing with here which is :so we have to hack the website using the webshell maybe?or get a reverse connection with something similar.Lets research something about thisLets postpone it and use gobuster to try to use another wordlist instead of dirb.gobuster dir -u http://10.10.10.181/ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -s 200,204,301,302,307,401 -o /home/MrRobot/Documents/Documents/BoxesHACK/Traceback/enumerationweb.txt3rd Step of the Process isExploitation and Examining With Different tools.lets start.nothing from ZAPlets run Raccoon and see if we can get something….raccoon 10.10.10.181wait for resultsnothing.I guess the standard steps doesn’t work lets try to do some OSINT on the target and try to get something usefulby looking at the main page’s sourcepage again we find something interesting :by googling this sentence we link to a github page with web shells names , first idea came to my mind is make a list of these webshells for enumeration with gobuster.https://github.com/TheBinitGhimire/Web-Shellsby running gobuster against this list , BINGO we can find the one url that will lead us to the target webpagesmevk.phpby entering admin admin as credentials we could guess it easily.we can login inside the main page ]]></description>
        <enclosure url="http://cdn-images-1.medium.com/max/682/1*Ugz4CH9LV18I_GB2G9lMkw.jpeg" length="49398" type="image/jpeg"/>
        <pubDate>Sun, 22 Mar 2026 15:40:54 -0400</pubDate>
        <dc:creator>Darpan Neupane</dc:creator>
        <media:keywords>TraceBack, Box, Writeup, From, HTB, DOT</media:keywords>
    </item>
    <item>
        <title>Obfuscation Isn’t a Fix, And It Cost Them $2,500 — A Real&amp;World Case Study</title>
        <link>https://cybersecuritytomorrow.com/obfuscation-isnt-a-fix-and-it-cost-them-2500a-real-world-case-study</link>
        <guid>https://cybersecuritytomorrow.com/obfuscation-isnt-a-fix-and-it-cost-them-2500a-real-world-case-study</guid>
        <description><![CDATA[ Obfuscation Isn’t a Fix, And It Cost Them $2,500 — A Real-World Case StudyChallenge AcceptedA while ago, I performed a penetration test on a major web application owned by one of my clients. During the assessment, I identified several critical vulnerabilities. Although these flaws weren’t easy to find — they required in-depth analysis and carefully crafted requests — they posed a serious risk to the platform’s integrity and user data.Given the severity of the findings, I expected the development and management teams to prioritize proper remediation. But instead, they chose a different path.Rather than fixing the underlying security issues, they decided to encrypt the entire body of each HTTP request— for example, encrypting login credentials or parameter values — in an attempt to prevent attackers from understanding or reproducing the vulnerabilities.Their idea was to “hide” the vulnerabilities behind encrypted traffic, giving them six months to work on actual fixes. In theory, this would slow down any attacker trying to identify or exploit the issues.I explained why this approach wouldn’t hold. Obscuring insecure functionality doesn’t make it secure — it just shifts the problem and adds complexity without eliminating the risk. I even challenged them: if I could still exploit the vulnerabilities despite the encrypted requests, they would pay me an additional $2,500.Spoiler: they did.Let’s walk through the scenario, why encryption is not a substitute for proper remediation, and what this taught both sides about the real cost of avoiding fixes.The first request is a POST request, in which data is sent encrypted within the HashData parameter. However, after decryption, the data appears to be unreadable.Encrypted RequestEncrypted ResponseUpon inspecting the JavaScript bundle (main.xxxxxxx.chunk.js), I identified a function named HashData, which was responsible for encrypting request data. This function was used in two key places, but only one of them leveraged a request interceptor pattern, which allowed injection or modification of outgoing payloads before being sent.HashData Function Used In First PlaceHashData Function Used In Second PlaceIn this case (Second Place), the developer has used an interceptor method for the request in order to apply modifications. We use a breakpoint to sniff and analyze it.Analyze HashData FunctionDespite the code being minified, I was able to use online tools to beautify it and analyze the logic.HashData FunctionThe encryption process involved the following:A random 256-bit key was generated for each request using a function like random().The request body was encrypted using AES, with this random key as the encryption key.The random key itself was then encrypted using a static RSA public key and attached to the request.The encrypted data was finally Base64-encoded and stored or transmitted (sometimes via localStorage or directly in the request).The AES encryption function is defined as follows:function s(e, t) {var n = t.toString();return r.a.AES.encrypt(JSON.stringify(e), n).toString()}e is the input data that gets converted to JSON and then encrypted.t is the encryption key.The function returns the encrypted result as a string (i.e., the server response).Here’s a simplified version of the AES encryption logic:function encrypt(data, key) {    return CryptoJS.AES.encrypt(JSON.stringify(data), key.toString()).toString();}The AES decryption function is defined as:function u(e, t) {    if (void 0 !== e) {        var n = r.a.AES.decrypt(e.toString(), t).toString(r.a.enc.Utf8);        return JSON.parse(JSON.parse(n).data)    }}e is the encrypted data.t is the encryption key.The decrypted result is parsed from JSON and returned as the original data.Here’s a simplified version of the AES decryption logic:function decrypt(encryptedData, key) {    const decrypted = CryptoJS.AES.decrypt(encryptedData.toString(), key).toString(CryptoJS.enc.Utf8);    return JSON.parse(JSON.parse(decrypted).data);}This means that the payload encryption relied entirely on a client-generated key — which I could capture at runtime using browser breakpoints — and a public RSA key for wrapping that AES key.On the server side, the process was reversed:The encrypted AES key was decrypted using the server’s RSA private key.That AES key was then used to decrypt the actual request body.The server-side implementation accepted requests with a validity window of around 30 seconds to prevent replay attacks. However, this still wasn’t enough to stop me.The 32-byte random array is stored across 8 stack slotse is encryption dataNow we need to simulate the encryption and decryption code (there’s no need to know the server-side private key). That means:If the unique code var n = t.toString(); appears in the response body, we log it as an encryption request.For decryption, if the unique code var n = r.a.AES.decrypt(e.toString(), t).toString(r.a.enc.Utf8); appears in the response body, we print the server’s response.Below, you  ]]></description>
        <enclosure url="http://miro.medium.com/v2/resize:fit:1200/1*_XKOWFHy83hP9B5ilqo72A.png" length="49398" type="image/jpeg"/>
        <pubDate>Sat, 19 Apr 2025 16:08:17 -0400</pubDate>
        <dc:creator>Darpan Neupane</dc:creator>
        <media:keywords>Obfuscation, Isn’t, Fix, And, Cost, Them, 2, 500 — A, Real-World, Case, Study</media:keywords>
    </item>
    <item>
        <title>TryHackMe: Pickle Rick Walkthrough</title>
        <link>https://cybersecuritytomorrow.com/tryhackme-pickle-rick-walkthrough</link>
        <guid>https://cybersecuritytomorrow.com/tryhackme-pickle-rick-walkthrough</guid>
        <description><![CDATA[ “Because science, Morty.”Continue reading on InfoSec Write-ups » ]]></description>
        <enclosure url="http://miro.medium.com/v2/resize:fit:1200/1*7eOieeiCee9HgQrIszR8Sg.jpeg" length="49398" type="image/jpeg"/>
        <pubDate>Sat, 19 Apr 2025 16:08:16 -0400</pubDate>
        <dc:creator>Darpan Neupane</dc:creator>
        <media:keywords>TryHackMe:, Pickle, Rick, Walkthrough</media:keywords>
    </item>
    <item>
        <title>Your NTLM Hashes at Risk: Inside CVE‑2025‑24054</title>
        <link>https://cybersecuritytomorrow.com/your-ntlm-hashes-at-risk-inside-cve202524054</link>
        <guid>https://cybersecuritytomorrow.com/your-ntlm-hashes-at-risk-inside-cve202524054</guid>
        <description><![CDATA[ NTLM (New Technology LAN Manager) is Microsoft’s legacy authentication suite, still found in many enterprise environments. NTLMv2 improves…Continue reading on InfoSec Write-ups » ]]></description>
        <enclosure url="http://miro.medium.com/v2/da:true/resize:fit:1200/0*5_Tsl8mIoMDYNXhu" length="49398" type="image/jpeg"/>
        <pubDate>Sat, 19 Apr 2025 16:08:15 -0400</pubDate>
        <dc:creator>Darpan Neupane</dc:creator>
        <media:keywords>Your, NTLM, Hashes, Risk:, Inside, CVE‑2025‑24054</media:keywords>
    </item>
    <item>
        <title>Burp Suite Beyond Basics: Hidden Features That Save Time and Find More Bugs</title>
        <link>https://cybersecuritytomorrow.com/burp-suite-beyond-basics-hidden-features-that-save-time-and-find-more-bugs</link>
        <guid>https://cybersecuritytomorrow.com/burp-suite-beyond-basics-hidden-features-that-save-time-and-find-more-bugs</guid>
        <description><![CDATA[ ????Free Article LinkContinue reading on InfoSec Write-ups » ]]></description>
        <enclosure url="http://miro.medium.com/v2/resize:fit:1200/1*Hr3ycIliCfyglthzeKkuJw.jpeg" length="49398" type="image/jpeg"/>
        <pubDate>Sat, 19 Apr 2025 16:08:14 -0400</pubDate>
        <dc:creator>Darpan Neupane</dc:creator>
        <media:keywords>Burp, Suite, Beyond, Basics:, Hidden, Features, That, Save, Time, and, Find, More, Bugs</media:keywords>
    </item>
    <item>
        <title>The Ultimate Guide to WAF Bypass Using SQLMap, Proxychains &amp;amp; Tamper Scripts</title>
        <link>https://cybersecuritytomorrow.com/the-ultimate-guide-to-waf-bypass-using-sqlmap-proxychains-tamper-scripts</link>
        <guid>https://cybersecuritytomorrow.com/the-ultimate-guide-to-waf-bypass-using-sqlmap-proxychains-tamper-scripts</guid>
        <description><![CDATA[ Mastering Advanced SQLMap Techniques with Proxychains and tamper scripts Against Cloudflare and ModSecurityContinue reading on InfoSec Write-ups » ]]></description>
        <enclosure url="http://miro.medium.com/v2/resize:fit:1200/1*R1yLRvHPAT-ikersHSkKGQ.png" length="49398" type="image/jpeg"/>
        <pubDate>Sat, 19 Apr 2025 16:08:12 -0400</pubDate>
        <dc:creator>Darpan Neupane</dc:creator>
        <media:keywords>The, Ultimate, Guide, WAF, Bypass, Using, SQLMap, Proxychains, Tamper, Scripts</media:keywords>
    </item>
    </channel>
</rss>