1

This is a real shot in the dark. I have a C# DotNet solution (Visual Studio 2010) that consists of the EXE and several class library support DLLs. The Solution uses SMO (SQL Management Objects) to connect to and browse a database.

One of the DLLs is being flagged as Ransomware by Windows Defender (Windows 10 Pro x64). Specifically Ransom:MSIL/Hasadcrypt.A. I ran the DLL through VirusTotal and nothing else is flagging it except Microsoft. It is without question not RansomWare. I don't even know where to begin to figure out what is causing it to be flagged. Any suggestions as to where to start would be greatly appreciated.

Neil Weicher
  • 2,370
  • 6
  • 34
  • 56

1 Answers1

-1

Some viruses encrypt themselves. I don't know what you may be doing to set off the alarms, but that's what I would look into. You didn't actually tell us what the file does, but you did leave that word "crypt" in the file name.

Did you create it yourself? How do you know for certain that "It is without question not RansomWare." And if it is self-modifying code, that is one thing that virus software looks at -- it allows the virus or malware to mutate, so as to avoid detection.

MicroservicesOnDDD
  • 332
  • 2
  • 12
  • "you did leave that word crypt in the file name" What makes you think that? OP hasn't told us his filename, only what malware Defender thinks it has detected. – Ben Voigt Feb 18 '20 at 15:43
  • He said, "Specifically Ransom:MSIL/Hasadcrypt.A. I ran the ", and I was wondering what "Hasadcrypt.A" was, in particular the "crypt" part, which he claims "is without question **not** ransomware", and I just wondered if he downloaded a virus and was assured and reassured that it was **not** a virus. – MicroservicesOnDDD Feb 18 '20 at 20:36
  • "Ransom:MSIL/Hasadcrypt.A" is what Windows Defender thinks it has detected. It's not a filename (`:` is not a legal character in a filename), but the name of a detection in Windows Defender's database of known malware. – Ben Voigt Feb 18 '20 at 21:04
  • @BenVoigt -- Sorry. I should have known that. But yet the word "crypt" in what the malware has been named in the Defender's database still may give us a clue that some kind of cryptography going on in the OP's file may be setting off the false positive -- or am I still totally off base? – MicroservicesOnDDD Feb 18 '20 at 21:16
  • That idea is a lot more reasonable, although IMO Defender would be triggering off of something far more unusual than merely calling cryptography functions. – Ben Voigt Feb 18 '20 at 21:24
  • @MicroservicesOnDDD - yes, we created the DLL ourselves which is how I know that it is not Ransomware. It does do encryption and decryption, so the best that I can figure is that it sees classes and methods with "encrypt" and "decrypt" in the names. As I mentioned, I submitted it to VirusTotal and nothing else flagged it except Microsoft. It could be that Microsoft detection is just dumber than the others. – Neil Weicher Feb 19 '20 at 09:05
  • @NeilWeicher - Or Microsoft has seen and now handles another pattern the others don't! I know this is a long shot, but do any of your DLL's perform self-modifying code or other "virus-like" behavior, especially self-encryption, self-decryption or other encryption/decryption where DLL's/EXE's are either the target or source? (which of course you could legitimately be doing as part of an in-house kind of copy protection or similar scheme?) Self-updating executables or DLL's might also look suspicious. – MicroservicesOnDDD Apr 27 '20 at 15:32
  • @MicroservicesOnDDD - no it doesn't. But I think I know what might be the trigger. The code contains classes, methods and properties with the names Encrypt and Decrypt in them. I think simply seeing them during a scan is triggering Windows Defender. Nothing more complicated than that. – Neil Weicher Apr 28 '20 at 16:04