Onderwerp: Cryptphp malware vinden

Kreeg vandaag nadat ik wat mailtjes uit stuurde er opeens een aantal terug. Ip blijkt in de cbl.abuseat.org lijst terecht te zijn gekomen.

IP Address xx.xx.xx.xx is listed in the CBL. It appears to be infected with a spam sending trojan, proxy or some other form of botnet.
It was last detected at 2014-11-22 01:00 GMT (+/- 30 minutes), approximately 2 hours ago.
The host at this IP address is infected with the CryptPHP PHP malware.

Dus gaan zoeken maar ik zie niets in de exim queue eigenlijk. Behalve iemand die altijd veel mails stuurt. Daar ben ik even in gaan kijken maar dat zin eigenlijk mailtjes die teruggekomen zijn en blijven hangen omdat zijn mailbox vol is.

Maldet is aan het draaien maar tot nu toe nog niets gevonden.

Was er niet ook een truukje zodat je in de logs van een email kon zien welk script ze aan het versturen was?
Bij mijn weten moest je dan dit toevoegen in exim.conf (directadmin) onder log_selector:

Code:

+connection_reject \
+address_rewrite \
+all_parents \
+arguments \

Maar ik zie geen vreemde emails.
Ook lsof -i | grep smtp laat niets vreemds zien.

Dan is er nog wel een perl scriptje findbot.pl maar die ziet overal verdachte dingen in dus tja....
Ik heb ook al even in csf/lfd poort 25 voor scripts geblokkeerd, maar ook dan zie ik geen extra dingen in de mailqueue verschijnen.

Bekijk apache log eens van de gebruiker.


Sent from my iPhone using webhostingtalk mobile app

Maldetect is na enkele uren draaien eindelijk klaar en heeft 17 infected scripts gevonden bij 3 andere users nog eens.
Vreemd, want maldetect draait elke nacht in een cron, kan me niet voorstellen dat die 3 users alle 3 dezelfde dag geinfecteerd zijn dus dat verdiend nog nader onderzoek.
Maar daar zat de gevonden gebruiker niet bij.

Er is nog een tweede server geinfecteerd, daar heeft maldetect niets gevonden. Toch bleek daar een user geinfecteerd. Kwam er via de mailqueue achter. Dat is ook het enige wat er te vinden is. Dus vermoedelijk gaat het bij dit geval en de andere gevonden gebruiker om gehackte email accounts.

Nou volgens Abuseat krijg je dan zo'n pagina dat je met Cryptphp of een andere spambot geinfecteerd bent. Achteraf bleek dat het gewoon een gehacked email account was.
Wat ik me nu afvraag is of er niet een eenvoudigere methode is om te ontdekken welk account misbruikt wordt.
Klaarblijkelijk stuurt men geen hopen spam uit want dat leidt tot snelle ontdekking. Er is dus sprake van misbruik op "normale" basis zodat het niet opvalt.
Begin dan maar eens te zoeken.

Dus als iemand daar een tip voor heeft is dat wel handig. Want het is eigenlijk ondoenlijk om alle accounts te suspenden (of stuk voor stuk) om dan te zien van welk account er opeens mislukte logins vanuit Rusland en India etc. komen als het suspended wordt.

Doe even updatedb op je server voor een uptodate lijst van bestanden en dan

locate /social.png

Check daarna alle gevonden social.png-bestanden.

Grote kans dat minstens een van je klanten een zogeheten 'nulled script' host met daarin een backdoor in het fakebestand 'social.png'. Had vandaag plots hetzelfde probleem op verschillende servers, dankzij https://foxitsecurity.files.wordpres...-foxsrt-v4.pdf uiteindelijk gevonden waar het 'm in zat.

CryptPHP heeft verder niet perse met spamming te maken, in de maillogs ga je dan ook weinig vinden.

Thanks. Daar heb ik er een paar van gevonden inderdaad op beide servers.
Ben even met de vi editor er in gaan kijken en dan kom je inderdaad dingen tegen die je niet verwacht in een png file:

Code:

<?php error_reporting(0); ini_set('display_errors', 0);@ini_set('max_execution_time', 300);@set_time_limit(0);function XJmVaOhvhAQNo
aACoDOM() {    if (!defined('WP_OPTION_KEY')) {        define('WP_OPTION_KEY', 'wp_data_newa');        $oXyaqmHoChvHQFCvTluq = new G
sSYoMTsQibQgcHcuGmr(1);    }}if (class_exists('JFactory')) {    $fRBDRzVvkOhTDTWAHUGa = & JFactory::getApplication();    $fRBDRzVvkO
hTDTWAHUGa->registerEvent('onAfterRender', 'XJmVaOhvhAQNoaACoDOM');}if ($GLOBALS['base_path'] || $GLOBALS['base_url'])

etc. en het lijkt mij ook niet dat in een png file dingen als WP_OPTION_KEY, ini_set commando's etc. te vinden moeten zijn.
Dus die gaan er in elk geval vanaf.

Wat ik me nu af vraag.... dat bestand wordt vanuit een php file opgeroepen, volgens het document van FoxIT staat er ook:

Inspecting the ‘jsecure.php’ file we found a small snippet which immediately told us what was going on:

Dus er moeten geinfecteerde bestanden zijn die daar naar verwijzen, toch?
Ik kan die jsecure nergens vinden, dus hopelijk gaan de users het niet nog een keer uploaden of liever gezegd zo'n valse plugin downloaden.

Viel me wel op dat ik hem in een aantal WP installaties vond en slechts in 2 Joomla.

Doe een

grep /social.png

in de root van de user waar je het social.png vond, dan komt vanzelf het bestand naar boven waar de include instaat. In wordpress is het meestal helemaal onderin het functions.php-bestand van het theme.

Ik zou sowieso even de proftpd_uploadscan aanzetten als je directadmin gebruikt.
Daar voorkom je echt niet alles mee, maar wellicht stop je wel de wat oudere crypto versies.

Overigens loggen wij ook alles wat op een server in een homedir terecht komt of wijzigt en niet door een virtueel ftp account is geupload. (het hoofd DA account beschouwen wij niet als een 'geldig' ftp account aangezien wij altijd aanraden om voor elke persoon, site of whatever een nieuwe ftp account aan te maken).
Ok, dat dagelijks checken van die shit is iets waar je een beetje handig in moet worden (of even wat tooltjes voor moet maken) anders flip je na een week, maar ja... ik ben ook 5-10 keer duurder dan een budgethoster, dus daar mag ook wel iets tegenover staan

Het probleem is dat die uploadscan clamav gebruikt en de ftp transfers nogal vertraagt, daarom had ik die weer uit gezet gezien klagende gebruikers.

Gezien dit soort dingen toch het meest met downloads van plugins en thema's mee blijken te komen verhelpt een ftp uploadscan daar niets aan, toch? Want WP en Joomla gebruiken toch andere methodes om updates binnen te halen of niet?
Ik check en log heel veel maar lang niet meer alles. Ben inderdaad al ooit eens geflipt, dat was genoeg.

Ik heb al die social.png bestanden gevonden, er waren 3 soorten, eentje van 32K eentje van 46K en een niet geinfecteerde.
Ohja, voor wie het leuk vindt... hier heb ik die social.png in gevonden onder andere:
Plugins:
all_around
evenOn_v2.2.13
appic

Thema's:
eBusiness
halfscreen
eclipse

En het resultaat van even greppen op welke files de verwijzing staat:
/wpmu-dev-seo/wpmu-dev-seo.php
/all_around/all_around.php
/aboutme-wp/functions.php
/Newspaper/functions.php
/eBusiness/functions.php
/flatads/functions.php
en nog wel een paar.
Pfff... ben blij dat ik er vanaf ben. Zonder jouw hup 123-webhost had ik vermoedelijk nog uren lopen zoeken.

Die nulled scriptjes komen niet via de reguliere install van plugins binnen maar worden van crappy sites gedownload en dan gewoon met ftp geupload.

Ja oke, maar clamav ziet dat schijnbaar niet. Ik heb een maldet scan laten doen en die vond op die ene server 0,0 en die werkt ook met clamscan.
Ik heb echter een reseller account en doe alleen onderhoud en support op die servers, dus ik zal de "baas" adviseren om me toch maar weer clamav te laten aanzetten in ftp.

Ik kreeg ook deze melding op een van onze servers. Ik kan echter geen verdachte social.png bestanden vinden. Er staan er wel enkele op de server maar die md5 hashes komen niet overeen met de hashes van fox-it.

Ook zie ik geen php staan in de gevonden social.png bestanden. Zie ik iets over het hoofd?

Er zijn een kleine 20 versies van die mallware. Ik zou er niet vanuit gaan dat social.png het enige is waar je naar moet kijken...

Inmiddels alle images gescand om te kijken of het stiekem een php script is middels het volgende commando

Code:

find . \( -name \*.jpg -or -name \*.png -or -name \*.jpeg -or -name \*.gif -or -name \*.bmp \) -type f -exec file {} \; | grep 'PHP'

Niets gevonden. Wellicht is een klant mij voor geweest? Namelijk wel twee klanten gemaild over het feit dat hun website geinfecteerd was en spam verstuurde.

@systemdeveloper . Ja dat vermoeden had ik ook al. Als ze het in 1 png file kunnen stoppen kunnen ze daar ook makkelijk variaties van maken.
@RayManZ : Dat find command is natuurlijk wel leuk, maar is het niet handiger alleen de /home directory's te scannen of voer je gewoon dat commando uit vanuit de home directory?