• Hello!

    My website got hacked quite a while ago and my host blocked it due to the security issue.

    As there was a list of dozens of files that were involved (and other, private, stuff going on), I couldn’t be bothered to fix it.

    So my wordpress version is 6.0.2

    Now I had the motivation to try to fix it and I realized that none of the files seemed to actually belong to wordpress, so I just deleted them.

    Now the host unblocked the site but now I’m only getting: Error establishing a database connection.

    The error log says:

    Date / Time / Domain Name

    [client 13.37.122.0] AH02811: stderr from /home/strato/http/power/rid/84/02/510138402/htdocs/wordpress/ss.php: script not found or unable to stat

    “Of course” I have no backup that I could use to fix issues. The file was one of those that I deleted, as far as I remember. At least it doesn’t exist.

    Does anyone have an idea how to fix this?

    Best regards,
    Pawel

Viewing 4 replies - 1 through 4 (of 4 total)
  • Ciprian

    (@butterflymedia)

    That file looks like malware, so you need to find out who is calling it. It could be somewhere in wp-config.php.

    Also, you could manually create an empty ss.php file in the root, so that you can log into the website.

    Thread Starter pawel2

    (@pawel2)

    Hello!

    Thanks for the reply. The config.php didn’t seem to be an issue and I can’t see anything suspicious. So far at least.

    Now I double-checked the database info (database name, user name, server address) and changed the database password just in case and updated it in th config.

    Now I’m getting instead of the previous error: There has been a critical error on this website.

    Adding an empty ss.php didn’t do anything. And I have doubts about there still being malware as I think the host wouldn’t have even unblocked the site.

    However, now I’m confused why the error changed only after changing the password, so I’m giving the complete content of the config.php for you to check, with passwords removed (XXXX)

    <?php
    /**
    * The base configuration for WordPress
    *
    * The wp-config.php creation script uses this file during the
    * installation. You don't have to use the web site, you can
    * copy this file to "wp-config.php" and fill in the values.
    *
    * This file contains the following configurations:
    *
    * * MySQL settings
    * * Secret keys
    * * Database table prefix
    * * ABSPATH
    *
    * @link https://codex.www.ads-software.com/Editing_wp-config.php
    *
    * @package WordPress
    */

    // ** MySQL settings - You can get this info from your web host ** //
    /** The name of the database for WordPress */
    define('DB_NAME', 'DB3901318');

    /** MySQL database username */
    define('DB_USER', 'U3901318');

    /** MySQL database password */
    define('DB_PASSWORD', 'XXXXX');

    /** MySQL hostname */
    define('DB_HOST', 'rdbms.strato.de');

    /** Database Charset to use in creating database tables. */
    define('DB_CHARSET', 'utf8');

    /** The Database Collate type. Don't change this if in doubt. */
    define('DB_COLLATE', '');

    /**#@+
    * Authentication Unique Keys and Salts.
    *
    * Change these to different unique phrases!
    * You can generate these using the {@link https://api.www.ads-software.com/secret-key/1.1/salt/ www.ads-software.com secret-key service}
    * You can change these at any point in time to invalidate all existing cookies. This will force all users to have to log in again.
    *
    * @since 2.6.0
    */
    define('AUTH_KEY', 'XXXXX');
    define('SECURE_AUTH_KEY', 'XXXXX');
    define('LOGGED_IN_KEY', 'XXXXX');
    define('NONCE_KEY', 'XXXXX');
    define('AUTH_SALT', 'XXXXX');
    define('SECURE_AUTH_SALT', 'XXXXX');
    define('LOGGED_IN_SALT', 'XXXXX');
    define('NONCE_SALT', 'XXXXX');
    /**#@-*/

    /**
    * WordPress Database Table prefix.
    *
    * You can have multiple installations in one database if you give each
    * a unique prefix. Only numbers, letters, and underscores please!
    */
    $table_prefix = 'wp_';

    /**
    * For developers: WordPress debugging mode.
    *
    * Change this to true to enable the display of notices during development.
    * It is strongly recommended that plugin and theme developers use WP_DEBUG
    * in their development environments.
    *
    * For information on other constants that can be used for debugging,
    * visit the Codex.
    *
    * @link https://codex.www.ads-software.com/Debugging_in_WordPress
    */
    define('WP_DEBUG', false);

    /* That's all, stop editing! Happy blogging. */

    /** Absolute path to the WordPress directory. */
    if ( !defined('ABSPATH') )
    define('ABSPATH', dirname(__FILE__) . '/');

    /** Sets up WordPress vars and included files. */
    require_once(ABSPATH . 'wp-settings.php');

    define( 'WP_ALLOW_MULTISITE', true );

    define ('FS_METHOD', 'direct');


    define( 'WP_AUTO_UPDATE_CORE', true );
    ?>

    It’s getting more and more confusing for me.

    Best regards,
    Pawel

    Moderator James Huff

    (@macmanx)

    Carefully follow this guide. When you’re done, you may want to implement some (if not all) of the recommended security measures and start backing up your site.

    Simply deleting the files will not fix an infection of your project. There can and will be other infected files hidden in subdirectories. The database itself will also be affected.

    Have a look at this article: https://www.ads-software.com/documentation/article/faq-my-site-was-hacked/

    The safest thing for you to do would be to delete the project (files and database) and restore it from a clean backup. Also change all access data in this case.

    If you don’t have a backup, ask your hoster’s support.

    If you don’t have a backup and want to continue running the project, you can try to clean it up manually. However, this can be a very tedious and nerve-wracking process. In this case, I would first delete everything outside of wp-content. Then look through all the files in wp-content individually – yes, there will be a lot of them. You can go by modification date, but I wouldn’t rely on it 100%. Then you can recreate the WordPress core files as described here: https://www.ads-software.com/documentation/article/updating-wordpress/#manual-update – then recreate wp-config.php as well, not from any backup, even if it seems clean to you.

    Once you have done this, take a look at this article: https://developer.www.ads-software.com/advanced-administration/security/hardening/

Viewing 4 replies - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.