Fabian Wosar

Emsisoft Employee
  • Content Count

    4405
  • Joined

  • Days Won

    1

Everything posted by Fabian Wosar

  1. A ton of applications do excessive DNS lookups. Your graphics card driver for example if you are a NVIDIA user. For some reason they think it's a good idea to resolve LOCALHOST several hundred times per second on some systems. So no, the number of DNS requests definitely isn't a good indicator for maliciousness.
  2. Most common case: They use a DGA to generate domain names, then try to resolve those names. If they don't find a name that resolves or if all the names are blocked by surf protection, they will never do anything that the BB could flag.
  3. Because you force the BB to do the reputation check by going to the list. The BB does not do a reputation check before then and naturally doesn't know what is and isn't bad because the reputation check is only triggered on observing a malicious behaviour. Obviously, we could add that it asks you to quarantine then. But that is not what you want. You want us to check the reputation of every application you start indiscriminately and quarantine automatically, which is something we won't do for privacy reasons. Because then we would know at any time exactly what applications you are running. You may be fine with that, but a tonne of other people would not.
  4. As mentioned before: It is working as intended. Doing what you ask would require us to send hashes of every single application you ever start to our server for checking. We won't do that, as it is highly invasive to your privacy. We most likely will never do that.
  5. Nevermind. Someone else reported a similar problem and provided the ransomware file. The decrypter has been updated accordingly. Please download it again and it should work just fine: https://decrypter.emsisoft.com/globe3
  6. Did you change the name of the encrypted file by any chance? It is important that you do not change the file names as they are used by the decrypter to determine the correct file extension for your system.
  7. @Jarkman I checked the files you provided. The version of the malware should be supported by the decrypter. Are you sure that the file pair you used is a match? Can you maybe look for a different file pair?
  8. That is technically impossible. The ransomware does not save the original timestamps anywhere. Therefore, the decrypter can't restore them. When you check your encrypted files, you will see that all the timestamps of those files are from the time of encryptiopn. Then you still haven't found the correct key based on the possible keys yet. I will require the ransomware executable from your system. This will usually be a file named Chrome_Font.exe which also encrypted your files initially. Without the file, there is nothing I can do for you. The decrypter is most likely busy attempting to figure out the key. On most systems, that shouldn't take too long. However, if your processor is a low budget or an older model, it may take some time. Just wait. Can you please provide the ransomware file from your system? This will usually be a file named Chrome_Font.exe which also encrypted your files initially. Without the file, there is nothing I can do for you. You need one file pair. Not the original files to all your encrypted files. One file pair is enough to extrapolate the encryption key and use that to decrypt all your other files. In the years I have been doing this there hasn't been a single case where a user genuinely wasn't able to find at least one original file to one of the encrypted files he has. To give you a few pointers: Were sample pictures or wallpapers encrypted, that ship with Windows? Just get the original files from a different system running the same Windows version. Were files you downloaded encrypted (check your Download folder)? Simply download the same file again. The Download history may come in handy for that (pressing CTRL + J in most browsers will bring it up). Were files encrypted that you recently shared with colleagues or friends/family? Simply get the original from your "Sent Mail" folder. There are literally dozens of ways.
  9. Get a few files, put them into a directory, try to decrypt the directory using the different keys, see if the files open. Repeat until you found the right one. You can also try to find a different file pair, which depending on the content, may result in less matching keys overall.
  10. Can you post the log of those files being decrypted and additionally:1. The malware file that encrypted your files.2. A file pair consisting of one encrypted and original file between 64 KB and 100 MB.3. Some of the files that don't decrypt properly.I will need all of that to figure out what is going wrong if anything goes wrong really.
  11. Es liegt nicht mal an der Erkennung, sondern an der Reinigung. Die 2 Misses sind "Partial Blocks", bedeutet wir haben beim Entfernen was uebersehen und die anderen Teile wurden erst nach einem Reboot entfernt. Kompromitiert wurde zwar nichts, allerdings zaehlt AV-T diese Dinge etwas strikter als AV-C.
  12. MRCR or Merry X-Mas is a ransomware family that first appeared in December last year. It is written in Delphi and uses a custom encryption algorithm. Encrypted files will have either ".PEGS1", ".MRCR1", ".RARE1", ".MERRY", or ".RMCM1" as an extension. The ransom note is named "YOUR_FILES_ARE_DEAD.HTA" or "MERRY_I_LOVE_YOU_BRUCE.HTA" and asks victims to contact either "[email protected]" or "comodosecurity" via the secure mobile messenger Telegram. The decrypter for this ransomware family can be found here: https://decrypter.emsisoft.com/mrcr Detailed usage instructions on how to use the decrypter are available here: https://decrypter.emsisoft.com/howtos/emsisoft_howto_mrcr.pdf Due to the mathematical properties of the encryption algorithm utilised by the ransomware, each file pair may have multiple encryption keys. The decrypter has, unfortunately, no way of knowing which one is the correct one. All keys will match for the provided file pair. However, only one of those keys will also match all other files. If the decrypter finds multiple keys, you will have to test the keys manually against some of your other files to find the correct one. To do that, simply attempt to decrypt some files, check the result and if the files are not readable, switch to the next key in the options tab and repeat the process.
  13. We usually handle License issues only via email, since we will need some personal information from you. I suggest you send an email to [email protected] I am sure we can arrange something (like turn your license into a 4 PC license with 522 days).
  14. Just released a new version (1.0.0.33) that should fix the problem: https://decrypter.emsisoft.com/globeimposter Can you verify that this new version no longer truncates the last 16 bytes in some cases?
  15. Siehe meine Aussage davor: Moeglicherweise inkorrekte Endung.
  16. Sollten problemlos unterstuetzt werden: (Filetype: '/.XLS/'; Offset: 0; Signature: ($D0, $CF, $11, $E0, $A1, $B1, $1A, $E1, $00, $00, $00, $00, $00, $00, $00, $00); SignatureLength: 9), (Filetype: '/.XLSM/'; Offset: 0; Signature: ($50, $4B, $03, $04, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00); SignatureLength: 4), (Filetype: '/.XLSX/'; Offset: 0; Signature: ($50, $4B, $03, $04, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00, $00); SignatureLength: 4), Wenn natuerlich die Dateiendungen nicht uebereinstimmen (z.B. eine XLSX Datei mit einer XLS Endung gespeichert wurde), dann ist der Decrypter nicht in der Lage das Format zu erkennen, weil nach den falschen Magic Bytes gesucht wird.
  17. As I said, opening that many handles at once causes issues on some systems. After that happens, the system is in an undefined state. That being said, the problem is not that the handles aren't freed, because they are, provided the system doesn't start acting all weird because too many handles have been opened. In either case, we switched it so we at most will open 2x the thread count of files during a scan task.
  18. The handles aren't leaked. They get freed up just fine. We just open up a lot of them at the same time in the first place, which on some systems causes issues. For the vast majority of our users, it doesn't cause any issues, and neither does it on any of our test systems.
  19. Das ist letztlich nicht so einfach. Jede Datei hat einen anderen Schluessel. Welcher Schluessel passt laesst sich nur ermitteln, indem ich mir das Resultat des Entschluesselungsprozesses fuer die Millionen an moeglichen Schluesseln anschaue um zu sehen ob das Ergebnis "Sinn" ergibt. Die Art und Weise wie das geschieht ist, dass ich die ersten 16 Bytes entschluessele und nach Formatspezifischen Magic Bytes suche. Der Decrypter erkennt letztlich ueber 4000 Dateiformate, aber das ist letztlich verglichen zu allen moeglichen Dateiformaten zu wenig. Dazu kommt, dass viele Formate gar keine Magic Bytes besitzen (Text Formate z.B.) oder aber die Magic Bytes schlicht zu wenige sind (Ist der Marker PK wie bei ZIP in den ersten 2 Bytes, hab ich eine 1:65536 Chance das da bei einem Key zufaellig PK raus kommt in den ersten 2 Bytes; bei einer Millionen Versuchen hab ich das nahezu garantiert einmal, was einem Fehlalarm entspricht und ich mit dem falschen Key decrypte). Theoretisch waere es ebenfalls moeglich die Keys basierend auf der Dateireihenfolge zu bestimmen. Allerdings ist das extrem riskant. Sollte irgendwo eine Datei fehlen, was dank dem "Optimierungswahn" von Leuten, die meinen CCleaner jeden Tag auszufuehren und der Tatsache, dass auch Temporaere Dateien verschluesselt werden koennen, durchaus der Fall ist, werden ab dem Punkt alle Dateien mit den falschen Schluesseln entschluesselt. Im Zweifelsfall kannst Du mir die Dateiformatspezifikationen der Dateiformate raussuchen, die dringend Notwendig sind. Dann kann ich dem Decrypter evtl. die Formate beibringen. Sollte dies allerdings nicht der Fall sein, kann ich leider nicht wirklich viel fuer Dich tun.
  20. Ich hab den Decrypter heute aktualisiert um die Variante die einen Mersenne Twister und SHA-512 benutzt um die Schluessel zu generieren zu entschluesseln: https://decrypter.emsisoft.com/nmoreira Die Variante wurde zwischen dem 29. November und 8. Dezember verbreitet. Alle Opfer die nach dem 8. Dezember kamen, sind hoechstwahrscheinlich von einer dritten Variante heimgesucht, die die Schluessel auf eine sichere Art und Weise generieren, die den im Decrypter genutzten Angriff unmoeglich macht. Sofern der Malware Autor also nicht seine privaten Schluessel leaked oder die Server von den Behoerden beschlagnahmt werden, werden weder ich noch sonst wer in der Lage sein diese dritte Variante zu entschluesseln. Bevor der Benutzung muss in den Optionen die korrekte Variante ausgewaehlt werden. Falls nicht bekannt ist, welche Variante die Dateien verschluesselt hat, kann man einfach an ein paar Bildern oder so testen.
  21. We have been able to reproduce this issue in the meantime. We have fixed the problem internally and hope to be able to provide a hotfix soon.
  22. Jede Anwendung die irgendeine Form von Eingabe verarbeitet ist letztlich ein zusaetzliches Risiko. Mehr Software bedeutet immer auch mehr Angriffsflaeche. Je komplexer die Aufgabe, je angreifbarer wird das ganze.
  23. Ist letztlich nichts neues und das Ganze Thema wird bei jedem neuen Taviso Bericht wieder aufgewaermt. Die Realitaet ist, dass Whitelisting nicht funktioniert, weil es bei weitem mehr legitime als Malware Dateien auf dem Planeten gibt. Wenn Du also jetzt schon nicht mit Malware Dateien hinterher kommst, wie es der Artikel behauptet, wie soll das ganze dann mit dem 100 - 1000 fachen Volumen aussehen? Niemand hat eine Loesung die wirklich besser funktioniert in der Praxis als AVs. Ansonsten haette sich so eine Loesung laengst etabliert.