{ "id": "daa44a84-341d-44b5-bcfc-91c080d86be0", "created_at": "2026-04-06T01:31:19.729148Z", "updated_at": "2026-04-10T03:23:51.279773Z", "deleted_at": null, "sha1_hash": "541a80bfc30bce279fc46ee41c7760c4e5647d0c", "title": "Incident report: Spotting SocGholish WordPress injection", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 1153933, "plain_text": "Incident report: Spotting SocGholish WordPress injection\r\nBy Tyler Fornes, Ryan Gott, Kyle Pellett, Evan Reichard\r\nPublished: 2021-07-22 · Archived: 2026-04-06 00:14:22 UTC\r\nEarlier this week, our SOC stopped a ransomware attack at a large software and staffing company. The attackers\r\ncompromised the company’s WordPress CMS and used the SocGholish framework to trigger a drive-by download\r\nof a Remote Access Tool (RAT) disguised as a Google Chrome update.\r\nIn total, four hosts downloaded a malicious Zipped JScript file that was configured to deploy a RAT, but we were\r\nable to stop the attack before ransomware deployment and help the organization remediate its WordPress CMS.\r\nWe’ll walk you through what happened, how we caught it, and provide recommendations on how to secure your\r\nWordPress CMS. We also hope that this story is a good reminder of the power of asking the right investigative\r\nquestions.\r\nHow we spotted our initial lead\r\nAround 07:00 UTC ( that’s 3:00 am ET), our SOC received an EDR alert for suspicious Windows Script Host\r\n(WSH) activity on one Windows 10 host.\r\nThe TL;DR is an employee double clicked a Zipped JScript file named “Chrome.Update.js” and EDR blocked\r\nexecution.\r\nHere’s what we were able to infer from our initial lead into the activity:\r\nThis doesn’t look like legitimate Google Chrome update activity\r\nPossible “fake update” activity delivered via Zipped JScript file\r\nhttps://expel.io/blog/incident-report-spotting-socgholish-wordpress-injection/\r\nPage 1 of 6\n\nThe activity is only on this host, not prevalent, and unlikely to be a false positive\r\nThe WSH process spawned from Windows Explorer, suggesting the employee double-clicked the JScript\r\nfile versus part of an exploit-chain\r\nInitial lead: suspicious WSH process activity\r\nAs part of our alert triage process, we did a quick check to make sure we weren’t seeing the WSH activity\r\nanywhere else in the environment.\r\nWe weren’t. And EDR blocked the activity.\r\nCase closed? Nope.\r\nThe quality of your SOC investigations is rooted in the questions you ask. There are two very important questions\r\nwe needed to answer before calling it “case closed:”\r\n1. What does the JScript file do?\r\n2. How did the Zipped JScript file get there?\r\nTo figure out what the JScript file does, we grabbed a copy of the Zipped JScript file and submitted it to our\r\ninternal sandbox (we use VMRay at Expel).\r\nThe JScript file did the following at runtime:\r\nContacted command-and-control servers hosted at [.]services[.]accountabilitypartner[.]com\r\n(195.189.96.41) and [.]drpease[.]com\r\nOpened an HTTP POST request for /pixel.png on TCP port 443\r\nDelivery mechanism consistent with potential SocGholish framework activity\r\nGiven this info, it’s our opinion that “/pixel.png” is likely a second stage payload. We were unable to acquire a\r\ncopy of “/pixel.png” for further analysis, but …\r\nhttps://expel.io/blog/incident-report-spotting-socgholish-wordpress-injection/\r\nPage 2 of 6\n\nBottom line: it’s bad.\r\nNow we needed to figure out how the Zipped JScript file got there.\r\nThis is where the story gets interesting.\r\nHow we investigated the SocGholish WordPress injection\r\nWe needed to know how the Zipped JScript file got onto the host computer. It would’ve been easy to assume,\r\n“Okay, the Zipped JScript file was likely delivered via phishing and EDR is blocking the activity, so we’ll block\r\nthe C2 and move on.”\r\n“Not so fast, my friend.” – Lee Corso\r\nUsing EDR live response features, we acquired a copy of the employee’s Google Chrome browser history as it\r\ncould potentially contain evidence we needed to determine how the Zipped JScript file got there. The host in\r\nquestion is a Windows machine, so we grabbed a copy of C:Users\\AppDataLocalGoogleChromeUser\r\nDataDefaultHistory” and reviewed it using internal tools. You can parse the History .db files using SQLite as well.\r\nSure enough, Google Chrome history recorded that “Chrome.Update.js” was downloaded after visiting a URL\r\nhosted on the company’s WordPress CMS. The company’s WordPress CMS was likely compromised, resulting in\r\ndelivery of “fake updates” that deploy the SocGholish RAT. The company’s WordPress CMS is publicly\r\naccessible, so anyone visiting the site could potentially be compromised.\r\nAt this point in our investigation, we declared a critical incident, notified our customer, and in parallel escalated\r\nour on-call procedure to bring in additional cavalry to aid in the investigation.\r\nGoogle Chrome history contained evidence to suggest that the malicious Zipped JScript file was downloaded after\r\nvisiting a webpage on the company’s WordPress site. We let our customer know that there was evidence to suggest\r\ntheir WordPress site was compromised and to invoke their internal Incident Response plan. We also armed the\r\ncustomer with information about command-and-control servers and advised them to implement blocks.\r\nAdding to the excitement, as the late night hours turned into early morning hours on the East Coast, our SOC\r\nstarted to receive additional EDR alerts for deployment of the malicious Zipped JScript on additional Windows 10\r\nhosts.\r\nEDR blocked that activity as well, but we needed to get a handle on the WordPress situation quickly. Anytime\r\nwe’d see a download of the Zipped JScript on a new host, we’d repeat our process to establish how the file got\r\nthere. In each case the Zipped JScript file was downloaded after visiting the company’s WordPress site.\r\nBut it turned out that multiple pages on the site were compromised, not just one. This context was super important.\r\nFor situational awareness, we did a quick check and noticed the company was running an older version of\r\nWordPress, 5.5.3. We didn’t have endpoint visibility into the WordPress server as it was hosted by a third party. If\r\nwe did, we would have wanted to establish when and how the site was compromised.\r\nhttps://expel.io/blog/incident-report-spotting-socgholish-wordpress-injection/\r\nPage 3 of 6\n\nWe inferred that the attacker likely exploited a vulnerability in a WordPress plugin or WordPress 5.5.3. We\r\ngrabbed source code of any page that was recorded as triggering a drive-by-download and got to work.\r\nWe almost immediately spotted a malicious inline script on every page that triggered a drive-by download:\r\nMalicious inline script deployed to multiple pages on the company’s WordPress site\r\nWe let the customer know about our findings and then turned our attention towards decoding and deobfuscating\r\nthe script.\r\nMost of the obfuscation consisted of base64 encoded functions and strings. With the help of the Chrome DevTools\r\nConsole, we stepped through the obfuscated script and eventually landed on the following:\r\nhttps://expel.io/blog/incident-report-spotting-socgholish-wordpress-injection/\r\nPage 4 of 6\n\nDecoded: malicious inline script deployed to multiple WordPress pages\r\nFrom the decoded script above, you’ll see that to trigger the drive-by download, the user must be referred to the\r\nsite (not referred from the same site) and be running Windows. The Zipped JScript was served from\r\nnotify.aproposaussies[.]com (179.43.169.30). At the time of writing, only Kaspersky (1/87) has flagged the\r\ndomain as malicious on VirusTotal.\r\nEverything is not fine.\r\nWe now understand what’s happening.\r\nAt this point, the customer was already in the process of removing the malicious inline scripts and updating to the\r\nmost recent version of WordPress.\r\nWe did one last check of the environment to make sure no additional hosts downloaded the evil Zipped JScript\r\nfile, checked to make sure that no hosts were talking to known C2 servers, and that no other malicious processes\r\nhad executed. We asked the right questions and in doing so, figured out what happened.\r\nA quick recap:\r\nhttps://expel.io/blog/incident-report-spotting-socgholish-wordpress-injection/\r\nPage 5 of 6\n\nThe attackers likely used the “SocGholish” framework to inject a malicious script into multiple pages on the\r\ncompany’s WordPress site by exploiting a vulnerability in a WordPress plugin or WordPress 5.5.3. If an employee\r\nnavigated to a compromised web page from a device running a Windows OS, an obfuscated inline script triggered\r\na drive-by download of a ZIP file with an embedded Windows JScript file. The malicious JScript file was\r\nconfigured to enable remote access to infected hosts by communicating with command-and-control (C2) servers\r\nhosted on legitimate compromised infrastructure. That remote access is then typically used to deploy variants of\r\nthe WASTEDLOCKER family of ransomware.\r\nLessons learned and tips to prevent similar incidents\r\nWordPress security and its ecosystem has improved over the years, but it’s still an attack vector. Keep up to date\r\non patches, but also:\r\nRun trusted and well-known WordPress plugins. These tend to have had more scrutiny and more focus on\r\nsecurity.\r\nFollow a WordPress hardening guide or install a WordPress security plug-in. There are many, so choose\r\none that is right for you.\r\nExplore implementing or updating your website Content Security Policy to block malicious scripts.\r\nMFA everything and all users.\r\nLock down your dev and staging instances, too (including adding MFA). You need to control the entire\r\nchain of the website, not just the final site.\r\nIf a third party hosts your WordPress site, have all the contact info and recovery info needed in case of an\r\nincident.\r\nRun an IR tabletop exercise where the initial entry point is your WordPress site.\r\nRemember, the quality of your SOC investigations is rooted in the questions you ask.\r\nIf we didn’t answer, “How did it get there?” we would have missed a huge finding that the company’s WordPress\r\nsite was compromised, resulting in drive-by downloads.\r\nSource: https://expel.io/blog/incident-report-spotting-socgholish-wordpress-injection/\r\nhttps://expel.io/blog/incident-report-spotting-socgholish-wordpress-injection/\r\nPage 6 of 6", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://expel.io/blog/incident-report-spotting-socgholish-wordpress-injection/" ], "report_names": [ "incident-report-spotting-socgholish-wordpress-injection" ], "threat_actors": [ { "id": "d90307b6-14a9-4d0b-9156-89e453d6eb13", "created_at": "2022-10-25T16:07:23.773944Z", "updated_at": "2026-04-10T02:00:04.746188Z", "deleted_at": null, "main_name": "Lead", "aliases": [ "Casper", "TG-3279" ], "source_name": "ETDA:Lead", "tools": [ "Agentemis", "BleDoor", "Cobalt Strike", "CobaltStrike", "RbDoor", "RibDoor", "Winnti", "cobeacon" ], "source_id": "ETDA", "reports": null } ], "ts_created_at": 1775439079, "ts_updated_at": 1775791431, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/541a80bfc30bce279fc46ee41c7760c4e5647d0c.pdf", "text": "https://archive.orkl.eu/541a80bfc30bce279fc46ee41c7760c4e5647d0c.txt", "img": "https://archive.orkl.eu/541a80bfc30bce279fc46ee41c7760c4e5647d0c.jpg" } }