application.bitcoinminer.adg botnet

#0: Du kan, hvis du synes, skrive IP adressen i browseren (viser; Mining Pool Online). Forbryderen ser ud til at befinde sig fysisk i Tyskland.

Den er hosted hos Hetzner som også bruges af mange danskere (jeg har fx selv en server hos dem), så selv om maskinen befinder sig i DE, er det ikke sikkert gerningsmanden/kvinden gør. Det kan også være en inficeret maskine som agerer vært for miningnetværket.

Kan du ikke i Windows se hvilken process der forbinder sig til den givne IP adresse?

#1: Kan du ikke i Windows se hvilken process der forbinder sig til den givne IP adresse?

Det er blandt hvad jeg endnu ikke har prøvet, eller rettere jeg har forsøgt, men uden resultat, for brugerens AV (Bitdefender) når at fjerne den her 11 tegns EXE fil før jeg får chancen. Starter jeg maskinen op i Safe Mode, så genereres filen ikke. Jeg har overvejet at afinstallere Bitdefender så processen ikke afbrydes.

Spørgsmålet er lidt om jeg skal koncentrere mig om at løse brugerens problem, hvad der er nemt nok ved at geninstallere systemet, eller om jeg skal give efter for min nysgerrighed.

Det er korrekt, som du nævner, at det ikke er sikkert at gerningsmanden/mændende befinder sig i Tyskland. Det er også interessant at vide hvordan maskinen blev inficeret i første omgang. Port 5555 er normalt lukket fra internettet, men ikke på LAN. Det kan skyldes en inficeret telefon tilsluttet LAN.

Jeg har ingen grund til at tro brugeren har gjort noget dumt med vilje. Hvis det skyldes en anden inficeret maskine tilsluttet LAN, så er der grund til at formode at det vil gentage sig.

Bitcoin malware, har også bredt sig til linux- installationer.
Her er det to meget kompetente brugere, der er ramt.
https://www.pclinuxos.com/forum/index.php/topic,146020.0.html

Malwaren stammer tilsyneladende, fra et "videre-udviklet" Kodi plugin.
Gemt i /home/"bruger"/.config, og kørt ubemærket her fra, uden "root" indblanding.

På den her installation, var bæstet hurtigt opdaget, da den forklædte sig, som en systemd service.

Vi skal nok til at være på vagt, og ikke regne med at være "fredet".

#3: Vi skal nok til at være på vagt, og ikke regne med at være "fredet".

Det tror du har ret i. Indikationen er i første omgang et urealistisk højt CPU forbrug.

En måde at holde øje med CPU forbruget på i real time, er at installere gkrellm. Gkrellm's utroligt grimme temaer, der udmærket kan afskrække nogen fra at installere, kan downloades og erstattes med transparente, hvis interessen er til stede. Gkrellm er ikke kun for sjov ...

https://www.dropbox.com/s/h8c31742mro48sy/gkrellm.png?raw=1

#3
Har også været kontaktet af en dansk Minecraft server hvor de havde spottet et suspekt højt CPU forbrug (normalt CPU forbruget er højt på Minecraft servere men ikke konstant 100% på alle kerner :P). Hvad vi fandt frem til her var at de var blevet hacket igennem et sikkerhedshul i phpbb hvor hackeren har fået indsat sin egen PHP side på serveren som indeholdt et temmelig imponerende interface med knapper til at udføre nærmest hvilket som helst hack på serveren.

Det snedige ved dette hack var dog at det ikke var muligt at finde programmet der kørte med 100% CPU fordi efter programmet blev startet sørgede hackeren for at slette programmet igen. Linux har intet problem i at slette et program der allerede kører da Linux vedligeholder en reference-tæller på alle filer hvor en reference både kan være en mappe der peger på filen eller en process der bruger filen. Så den slettede fil vil ikke kunne findes med "ls" men filen er der stadig fordi en process bruger filen men vil blive slettet når processen stoppes.

Så vores lille "problem" ville forsvinde ved en genstart men det er jo ikke ret sjovt da vi så ikke kan se hvad serveren stod og brugte alt sin CPU på. Et tip i sådan en situation er at kigge i /proc mappen. Alle processer der kører på systemet har et PID (Process ID) og hver kørende process har en mappe i /proc/{PID}. Det skal siges at dette ikke er "rigtige" mapper der ligger fysisk på din disk. Derimod er hele /proc et virtuelt filsystem oprettet med det formål at du nemt kan tilgå interne detaljer om Linux kernen.

Nå men ved at bruge top kunne jeg finde frem til PID på den process der brugte alt CPU og kunne så gå ind i mappen /proc/{PID}/fd. fd står for File Descriptor og er links til filer (samt sockets, pipes osv.) som er åbne af den given process. Alle "filer" i denne mappe er symlinks navngivet ud fra det ID nummer de hver har fået internt i den kørende process. Ved at bruge kommandoen "ls -ls" kan man se hvad disse ID'er står for. Fx har jeg taget følgende fra en Plex service:


....
0 lrwx------ 1 plex plex 64 Jun 6 06:58 660 -> socket:[444067139]
0 lrwx------ 1 plex plex 64 Jun 6 06:58 661 -> socket:[444508835]
0 lrwx------ 1 plex plex 64 Jun 6 06:58 662 -> socket:[444990305]
0 lrwx------ 1 plex plex 64 Jun 6 06:58 663 -> socket:[445518132]
0 lrwx------ 1 plex plex 64 Jun 6 06:58 664 -> socket:[445920634]
0 lrwx------ 1 plex plex 64 Jun 6 06:58 665 -> socket:[446247557]
0 lrwx------ 1 plex plex 64 Jun 6 06:58 666 -> socket:[446507341]
0 l-wx------ 1 plex plex 64 Jun 6 06:58 667 -> /var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Logs/Plex Media Server.log
...


Disse links er hardlinks og derfor en lige så valid reference til en given fil som hvis en mappe pegede på filen. Dette er årsagen til filer ikke fysisk bliver fjernet fra disken før alle processer, der bruger en given fil, er lukket ned eller færdig med at bruge filen. Man kan kalde det en slags "garbage collection med reference tællere".

Nå men via dette var det muligt for mig at få fat i de process filer som vores lille "problem" benyttede sig af. Jeg kopierede derved alle filer ned på min maskine. Nu er det ikke fordi jeg har lyst til at forsøge at køre programmet på min egen maskine så jeg benyttede mig af https://dply.co/ til at få en gratis midlertidig Linux server til at lege med denne "virus". Det er faktisk en virkelig nice service eftersom du hurtigt kan oprette midlertidige servere som bare nedlægges igen.

Jeg startede programmet op og kunne se at det bare var en alm. Monero coin generator hvilket meget godt forklarede det høje CPU forbrug. Desværre så læser programmet sin konfiguration fra en fil som efterfølgende lukkes så denne er ikke muligt at finde via FD mappen. Kunne derfor heller ikke se hvilken Monero adresse som pengene blev genereret til.

Det ville nok være muligt at finde denne oplysning via et dump af hukommelsen for processen men ærlig talt så havde jeg brugt tid nok på dette lille projekt så vi lukkede hullet i PHP samt genstartede serveren. Ejeren fil besked på at nulstille filerne på webserveren samt tjekke alle backup filer (især dem der blev hostet på hjemmesiden), hente en ny installation af wordpress og phpbb frem for at genbruge den fra backup samt sikre at ingen bruger uploadet filer indeholdt PHP kode. Desuden skulle ejeren notificere alle brugere om at der havde været et databaselæk og derfor potentielt et tab af passwords (dog hashet og med salt).

En positiv ting ved det hele var at webserveren kørte som sin egen bruger så hackeren har "kun" kunne få fat i MySQL samt webfilerne. Dette er slemt nok men hackeren har ikke kunne ændre på filer ude på selve systemet.

Nå det blev et længere skriv men håber i fandt det interessant. Moralen er at du skal huske at holde din software opdateret. Hacket der blev udnyttet i phpbb var lukket for lang tid siden så serverejeren var fuldt ud selv skyld i problemet. Regn altid med der står en bot ude i verden der forsøger at udnytte gamle sikkerhedshuller :)

#4
Jeg har altid en CPU-belatnings indikator kørende i bundpanelet.
Uundværlig.

#5
Meget interessant, detektiv arbejde.
Almindelige brugere, går oftest i panik, og sletter alt, uden at undersøge, hvor skidtet kom fra.

#5: Det er faktisk en virkelig nice service eftersom du hurtigt kan oprette midlertidige servere som bare nedlægges igen.

Desværre er der midlertidigt lukket for oprettelse af nye servere:

New account creation is temporarially unavilable: Dply is a personal project built to provide a resource to developers. The goal of Dply has always been to break even, having paid servers cover the costs of the 2hr free servers. Unfortunately some individuals choose to take advantage of this goodwill by mass-creating accounts in order to avoid paying. Currently, in any month that Dply does not cover it's costs I am personally paying for these servers out of pocket.
Because of a few users creating multiple accounts and thousands of servers almost every minute of development time put into Dply in the last year has been to combat this yet it remains a very serious issue. I have temporarially disabled new account creation in order to step back and re-evaluate the Dply service.

#5 #6 #7

Heldigvis kan man selv foretage undersøgelser af problemer med brug af virtuelle installationer, der helt på samme vis kan nedlægges efter brugerens eget behov. Online services er blot en metode, heldigvis ikke et krav.

Please stay independent, always ...

#8: Heldigvis kan man selv foretage undersøgelser af problemer med brug af virtuelle installationer, der helt på samme vis kan nedlægges efter brugerens eget behov

Helt enig, men fordelen ved https://dply.co/ er at den er "i luften" og man kan give andre adgang. Det kan man selvf. også med virtuelle maskiner, men det er et større arbejde.

Til eget brug vil jeg helt klart bare lave en virtuel maskine. Eller bruge en eksisterende maskine som man tager et snapshot af inden man leger.

#9:

Korrekt. For at forbedre sikkerheden iht en virtuel installation, hvis foremålet er undersøgelse af malware, iht folk der ikke er vant til VM, så kontroller at den virtuelle installation ikke er bridged og shared folders er deaktiveret. Det gælder også iht et snapshot af et allerede inficeret hardware installeret OS, der er virtuelt konverteret.

Det medfører det virtuelle OS kører på sit eget IP-LAN segment, hvilket sikrer at malware, installeret på gæsten, ikke har adgang til værtsmaskinen og derfor heller ikke til øvrige LAN tilsluttede maskiner, der varetages af den primære router.

Ønsker man andres adgang til det virtuelle OS, hvilket ikke er ønskeligt iht undersøgelse af fx bitconminer malware, eftersom de er smittefarlige, så kan det naturligvis lade sig gøre, men det et andet scenarie.

I den forbindelse er det centralt at forstå at et virtuelt OS er installeret lokalt på LAN, og derfor har afgang til åbne porte på brugerens lokale netværk, med mindre bridged netværk, og delte mapper med værten er fravalgt.

Default installerede VM's kører sædvanligvis på deres eget virtuelle LAN segment (virtuelle netværkskort), der ikke har forbindelse til det fysiske LAN. Blot til orientering.

For en ordens skyld er botnet virussen nu helt fjernet.
Den viste sig at stamme fra en falsk Windows Power Manager og srvany.exe i en mappe (Ccc) i Windows biblioteket.

Disse site info hjalp med at at identificere malwaren: https://www.isthisfilesafe.com/product/bcdb.exe_details.aspx
https://www.file.net/process/srvany.exe.html

Programmer nødvendige for fjerne infektionen:
Security Task Manager (til at vurdere risici)
rkill.exe (for at tvinge processen til at stoppe)
FRST (Farbar Recovery Tool, for at kontrollere processer før og efter fjernelse)

Det er også, for en ordens skyld, en god ide at tilføje:
127.0.0.1 pool.supportxmr.com til hosts filen, for at forhindre identificerede forbindelser og porte, der ikke er dækket i #0 , i at oprette forbindelse.

Hvis din router understøtter udelukkelse af websites, og du ikke miner crypto valutas fra pool.supportxmr.com, så kan du med fordel udelukke pool.supportxmr.com fra forbindelser til dit lokale hjemme-netværk.