In last week’s post, we reported on some concerning code identified in the Pipdig Power Pack (P3) plugin. The plugin, which is installed alongside WordPress themes sold by Pipdig, was found to contain a number of suspicious or malicious features. Among these features were a remote “killswitch” Pipdig could use to destroy sites, an obfuscated function used to change users’ passwords, and code which generated hourly requests with the apparent intent of DDoSing a competitor’s site.
In the days since we published that report, Pipdig has taken a series of increasingly questionable steps in their attempts to mitigate the fallout of their actions. Their team has issued baseless accusations that facts have been fabricated, collusion between their competitors had taken place, and that no wrongdoing of any sort had occurred.
These assertions stand in direct conflict with their actions. They’ve pulled down incriminating files from their sites, pushed undocumented updates to their plugins to remove additional malicious code, and have attempted to rewrite history by modifying dates of changelog entries. Then, perhaps most egregiously, Pipdig took down the Bitbucket repository containing a great deal of evidence of these actions. All of this had been done while an entire community of WordPress developers watched.
In today’s followup, we’ll use Pipdig’s official responses to recap their documented offenses. Then, we’ll discuss the timeline of events in the deployment and subsequent removal of Pipdig’s malicious code. After that, we’ll look at the evidence they’ve made efforts to destroy. Last, we’ll reveal new evidence that Pipdig’s suspected DDoS campaign against their competitor had still been active until April 1st, using Blogger themes.
In the uproar following the publication of their missteps, Pipdig released (and subsequently updated) a statement with the intent of dispelling the controversy. Unfortunately, instead of admitting fault and apologizing to their users, Pipdig leaned into a series of accusations and denials.
Let’s take a look at the individual points of these responses, and why each fails to help Pipdig’s cause. We’ll avoid using code samples in this section, though the Timeline section that follows will contain code as evidence.
In our report, we explained how a cron (scheduled process) built into the P3 plugin was effectively asking Pipdig’s server every hour for permission to destroy the database of the site it’s running on. Pipdig hasn’t denied that the code existed, but has attempted to “rebrand” the behavior in a number of ways. Read more