Malware (PHP-bestanden en lege mappen) in root website

Ik kreeg van mijn host een (automatische) mail dat er malware was gedetecteerd op mijn webhosting (mooibarradeel.nl). Welke bestanden werden geïnfecteerd?

• www/8fc9835b05eb.php 
• www/c7909/index.php

Ik vond deze bestanden in de root van mijn website en verwijderde die. Dat deed ik ook met een vijftal lege mappen (met letters/cijfers) in de root, die ik niet had aangemaakt..

Daarna worden nog steeds nieuwe verdachte php-bestanden in de root geplaatst. 

Met Malware Scan kwam ik erachter dat deze php-bestanden het volgende risico vormen: 
eval(base64_decode()) chain

Wie heeft een goede suggestie hoe ik hier vanaf kan komen? 
Ter aanvulling:ik ondervind verder geen problemen met de website.

Met vriendelijke groet, 
Meindert van Dijk

Het zou de JCE hack kunnen zijn. Daar kan je hier meer over lezen.

Bedankt voor je tip, Youll. 

Ik vermoed nu ook dat het de JCE hack is geweest. 

Het lukte mij niet om MySite.guru te installeren op mijn site, de plugin werd ergens 'tegengehouden'.
Ik heb wel op allerlei plaatsen gezocht naar verdachte bestanden en deze vooral gevonden in de root van de website en in de map /assets/images. Deze bestanden werden steeds verwijderd. 

Nadat bleek dat de ongewenst bestanden steeds terugkwamen nam ik contact op met mijn host, Combell, die afgelopen dagen een 'SiteSweep' heeft uitgevoerd. Dat resulteerde in een schone website, dacht ik. Ik maakte meteen een nieuwe backup, actualiseerde opnieuw alle wachtwoorden en maakte een nieuwe backup.

Toen ik vandaag opnieuw een backup maakte kreeg ik een melding (die ik nooit eerder kreeg):

WarningsUnreadable file /data/sites/web/mooibarradeelnl/www/8fc9835b05eb.php. Check permissions Cannot list contents of directory /data/sites/web/mooibarradeelnl/www/assets -- PHP reports it as not readable.Unreadable directory /data/sites/web/mooibarradeelnl/www/assetsCannot list contents of directory /data/sites/web/mooibarradeelnl/www/assets -- PHP reports it as not readable.

Toen ik vervolgens met PHP de bestanden van mijn site bekeek zag ik daar de volgende vreemde bestanden:

• www/8fc9835b05eb.php (zonder properties!)
• databfdf31index.php

Verder kreeg ik geen toegang meer tot de map www/assets. Deze map bleek ook geen properites te hebben. Nadat ik deze had toegevoegd kon ik er wel inkomen. Het bestand assets/images/accesson.php kon ik niet verwijderen. Dat lukte wel door de map /assets/images te verwijderen. 

Het bestand databfdf31index.php, dat in de root stond bleek een uitgebreid script te bevatten. 
De inhoud daarvan heb ik ter beoordeling voorgelegd aan Claude AI, die mij het volgende schreef:

"Dit is zonder twijfel een kwaadaardig bestand, en een ernstig soort: het is geen simpele geïnfecteerde pagina, maar een volledige "file manager"-achterdeur (webshell). Het bestand geeft iemand die het wachtwoord kent volledige controle over bestanden op je server: mappen bekijken, bestanden lezen, schrijven, uploaden, hernoemen, verwijderen en rechten wijzigen — allemaal via simpele webverzoeken, buiten Joomla en je inloggegevens om. En dat "geheime" wachtwoord blijkt letterlijk 123456 te zijn, dus praktisch geen beveiliging.Belangrijk: omdat dit bestand volledig los van Joomla werkt met zijn eigen ingebakken wachtwoord, heeft het wijzigen van je Joomla-, FTP- of databasewachtwoorden hier geen enkel effect op. Dit bestand moet fysiek verwijderd worden.Nog belangrijker: de bestandsnaam — een reeks willekeurige letters/cijfers gevolgd door "index.php" — is precies hetzelfde patroon als de bestanden die helemaal aan het begin zijn gevonden (8fc9835b05eb.php, 61b542b8e0index.php). Dat is een sterke aanwijzing dat dit dezelfde aanvaller(s) zijn, en dat de kwetsbaarheid die de eerste keer misbruikt is, ondanks de SiteSweep-opschoning nog steeds open staat."

Als jullie belangstelling hebben wil ik het hele script hier wel plaatsen, maar voor nu laat ik dat maar achterwege. 

Inmiddels heb ik Combell (mijn host) gevraagd om verder maatregelen te nemen om dit kwaadaardige script volledig te verwijderen, waarbij ik hen ook attendeerde op de mogelijke JCE-hack. 

Ik wilde jullie hiervan even in kennis stellen. Verder wacht ik de resultaten van Combell maar af.

Vervelend verhaal, en dat je bestand met permissie-trucjes onleesbaar werd gemaakt is inderdaad een teken dat de aanvaller weet wat hij doet — dat is niet zomaar een geautomatiseerd scriptje meer.Twee dingen die ik zou checken vóórdat je verder gaat opschonen:

1. Kijk in je Joomla-gebruikersbeheer of er geen onbekende Super User-accounts bijgekomen zijn. Dat is vaak hoe zo'n webshell na opschonen weer terugkomt.
2. Is de JCE-editor zelf al bijgewerkt/verwijderd? Als het lek nog open staat, blijft dit gebeuren, ongeacht hoeveel bestanden je of Combell weghaalt.

Dit soort hardnekkige hack-gevallen komt op joomlanl.nl vaker voorbij en daar zitten ook mensen die dagelijks met dit soort webshells bezig zijn — misschien handig om je verhaal daar ook te plaatsen, dan heb je meer ogen die meekijken. Succes in ieder geval, en hou ons op de hoogte van wat Combell vindt.

Bedankt voor je reactie, Henk.

In mijn Joomla-gebruikersbeheer sta alleen ikzelf met mijn eigen inlog-accounts, waarvan één Super User-account. De rest alleen geregistreerde accounts. Ik sta geen accounts van anderen toe.

De JCE-editor is allang bijgewerkt. Eigenlijk werkt ik nieuwe updates zo snel mogelijk bij, zo mogelijk nog dezelfde dag. Maar als ik enkele dagen van huis ben lukt dat niet. En dat kan tegenwoordig al fataal zijn...

Bedankt voor de tip over Joomla!NL. Ik heb me daar ook geregistreerd op het forum.

Overigens kwam ik bij het checken van de AWStats van mijn website ook een verdacht bestand tegen:
/components/com_allvideoshare/layouts/lindex.php — 49 keer bekeken, 35.77 KB gemiddeld
Let wel: hierbij staat er een l-teken voor index.php. Dit bleek ook een kwaadaardig bestand te zijn en is door mij verwijderd.

Ik heb met behulp van Claude (AI) het AWStats Pages-URL-rapport van september laten beoordelen. Hierbij de resultaten:Aanvullend bewijs uit het AWStats "Pages-URL"-rapport (september): Bij het doorlopen van de bezoekersstatistieken zag ik dat een aantal bestanden herhaaldelijk is opgevraagd én daadwerkelijk inhoud teruggaf (dus geen 404), verspreid over meerdere mappen:

• /8fc9835b05eb.php – 66 hits deze maand (gemiddeld ~2x per dag)
• /components/com_allvideoshare/layouts/lindex.php – 49 hits, 35,77 KB
• /databfdf31index.php – 42 hits, 2,52 KB
• /lindex.php – 18 hits, 20,51 KB
• /e1dc3456c9index.php – 15 hits, 30,74 KB
• /administrator/includes/data4d28a3index.php – 1 hit
• /cache/log6addd2index.php – 1 hit
• /language/cfgf20264index.php – 1 hit
• /phocamapskml/log4734fbindex.php – 1 hit
• /w/load.php – 1 hit, 270,52 KB
• /wp-content/plugins/litespeed-cache/guest.vary.php – 2 hits, 107,01 KB (let op: mijn site is Joomla, een wp-content-map hoort hier niet te bestaan)

Opvallend patroon: een willekeurige hexreeks gevolgd door "index.php" (databfdf31index.php, e1dc3456c9index.php, cfgf20264index.php, log4734fbindex.php, data4d28a3index.php) komt terug in minstens vijf verschillende mappen door de hele site heen (root, cache, language, administrator/includes, phocamapskml). Dat wijst erop dat het niet om één geïsoleerd bestand gaat, maar om meerdere verspreide backdoors die bewust in verschillende mappen zijn geplaatst.Mogelijk is deze informatie voor jullie ook interessant, voor mij reden om deze informatie ook hier te delen.
Ik stuur deze gegevens ook door naar Combell (mijn host), die de informatie kan benutten voor het (opnieuw) verwijderen van de malware met behulp van 'SiteSweep'. Ik hoop dat dit nu écht wordt opgelost. 
 

Zoek met google op site:mooibarradeel.nl en dan zie je dat de hack die er mogelijk mee te maken heeft  ook je website misbruikt voor eigen gewin. Het kan je vindbaarheid schaden. Die linkjes kunnen opduiken in google zoeken. Je ziet ook dat jouw favicon is aangepast. Op deze manier werd ik op het spoor gezet van een hack die grote overeenkomsten heeft met wat jij beschrijft. Ook gehost door combell. Met SSH kwam ik erachter dat er een key bestond van een onbekende. Combell heeft mij nog niet hierover ingelicht hoe dat komt. De hack die opp diverse websites plaatsw vond was in de meeste gevallen niet te verwijderen (een tijds issue) waardoor ik mijn toevlucht nam naar een akeeba backup. De hacker kon ook uploaden naar de homedir bij sommige sites. Onderzoek heeft JCE aangetoont ( dat was niet zo moeilijk vanwege de aandacht die deze extensie kreeg, maar ook Sourcerer van regular labs en SP PageBuilder waren zwakke schakels. De hacker (s) plaatsten diverse backdoors / webshells. Na verwijderen van duizenden ( tegen de 10:000 op een bepaalde website) htaccess bestanden, talloze wp mappen (met een wordpress naam) en php bestanden kwamen dezelfde bestanden na zeer korte tijd weer terug. Dat was een backdoor persistence / reinfectie of self-healing” malware-netwerk. De akeeba backup had mij gered, maar ook daar moest ik vreselijk veel checken, omdat de backdoor ook daar in zou kunnen zitten. ( als je dat doet gebruikdan een htaccess en voeg alleen je eigen IP toe, anders dweil je met de kraan open (met het riool open bedoel ik . Er zit niet zozeer een persoon achter ( ja ok uiteindelijk wel, maar das heel heel lang zoeken. En een IP blacklist in je htaccess is geen overbodige luxe als je de originele htaccess weer terug zet na de akeeba backup. Backup van de hoster zou natuurlijk ook mooi zijn, maar dioe gaat meestal niet verder terug dan een week). Ik heb nu weinig tijd om klussen als deze aan te nemen, maar probeer het gerust te vragen als je website is gehacked en je komt er niet meer uit.

Pffff..... Dat werpt weer een nieuw licht op deze vervelende hack. In elk geval dank voor je reactie, Wim.
Ik vraag mij af of ik het zo nog wel leuk vind om opnieuw zoveel tijd en energie te steken in het herstellen en malware vrij maken van deze website. 

Ik heb wel backups, maar vraag mij af hoe lang ik terug in de tijd moet gaan om een gegarandeerd malwarevrije backup te kunnen terugzetten. Daarbij komt dat ik juist afgelopen weken veel informatie had toegevoegd aan deze website. 

Ik denk dat het beter en veiliger zou zijn om de website weer helemaal opnieuw en schoon op te bouwen. Maar ik heb daar eerlijk gezegd weinig zin meer in.

Ik zal jouw informatie doorgeven aan Combell en ben ben benieuwd wat ze ermee zullen doen.

als zo'n backup voor juni of juli ligt dan zou ik dat zeker overwegen als redmiddel en inhoud die je hebt toegevoegd copy paste uit artikelen ergens opslaan en na de backup weer toevoegen. Maar dat moet je dus wel doen met een htaccess aanpassen waarmee jezelf alleen toegang krijgt, tijdelijk. Na alle updates en upgrade kun je de site weer open stellen voor iedereen. Maar ik check daarbij continu met chatgpt die mij goed heeft geholpen en inzicht heeft gegeven in dit soort hacks. 
Ik doe dit voor mijn werk, dus ik moet wel. 
Een compleet nieuwe site is dus echt niet nodig als je een backup hebt van voor juli of juni. Ik heb chatgpt ook laten checken of die backup wel betrouwbaar is. Dat is heel veel controleren met SSH bash / powershell wanneer de eerste succesvolle aanval werd gepleegd. Het kan dus ook eerder zijn dan die maanden, maar gezien de berichten van JCE, Sourcerer en SP pagebuilder zijn de lekken gedicht na hun eerste update toe het lek bekend werd. Dus daar valt ook te achterhalen welke periode je moet kiezen. 
Gedoe, hoop werk, maar geeft wel voldoening als je het achter de rug hebt. 
Daarna een extensie als akeeba admintools PRO overwegen dus met WAF. Schijnt geen overbodige luxe te zijn.
Succes!