And if the isaerp.com.br been a ssl cert? It helps for it do not be a FP?
Anyway am i talking about the code digsig with my team.
Not much - we do not check what SSL cert the domain has that the downloaded file came from.
Cool!
But if the domain is ssl cert, it’s reliable, doesn’t?
By the way, thank’s! If i need more help, i back on this post ou open another referencing this?
No, it only means that data traffic encrypted.
It doesn’t say anything about the reliability of a site.
Cool, tks
When you have the digsig, let us know here. If there is a completely unrelated issue, you may of course start a new thread 
Fine, tks HonzaZ, are you helped me a lot. If i answer an NPS Query now, are you receive a 10 from me, hahaha
Hi Lisandro,
I think your remarks are valid ones. I also find that infrastructure there quite questionable.
isaerp dot com dot br redirecting to asseinfo and in particular fake Googlebot activity (that means in a lot of cases cloaking activity) on for instance: htxps://d335luupugsy2.cloudfront.net/http://www.asseinfo.com.br/wp-content/themes/asseinfo/js/loader-scripts/6901f2e6-ce31-4235-9af7-012e51dd524a-loader.js
Re: https://sritest.io/#report/2fc3e274-c7f1-49e6-a280-693d7257691c
Scan info: https://aw-snap.info/file-viewer/?tgt=https%3A%2F%2Fd335luupugsy2.cloudfront.net%2Fhttp%3A%2F%2Fwww.asseinfo.com.br%2Fwp-content%2Fthemes%2Fasseinfo%2Fjs%2Floader-scripts%2F6901f2e6-ce31-4235-9af7-012e51dd524a-loader.js&ref_sel=GSP2&ua_sel=ff&fs=1
While it comes up as forbidden, does not mean we have to take the hidden activities going on there at face value!
See C status here with a subroutine aka same origin script issue here: https://d335luupugsy2.cloudfront.net/http://www.asseinfo.com.br/wp-content/themes/asseinfo/js/loader-scripts/6901f2e6-ce31-4235-9af7-012e51dd524a-loader.js
Also consider the issues here: (1 error and 5 warnings): https://mxtoolbox.com/domain/isaerp.com.br/
Then we have this to consider: Certificate is not installed correctly
isaerp.com.br
You have 1 error
Wrong certificate installed.
The domain name does not match the certificate common name or SAN.
*.websiteseguro.com, websiteseguro.com THAWTE SHA256 SSL CA
Strict Transport Security (HSTS):
Not Enabled
SSL/TLS compression:
Not Enabled
RC4:
Not Enabled
OCSP stapling:
Not Enabled
Amazon Seattle - Cloudfront know exactly what is going on on their servers, but they only provide the service and not interested on what they transport, from the configurations I assume the traffic could be open to abuse, also in the light of above scan results and insecurity detected.
polonus (volunteer website security analyst and website error-hunter)
Hi Polonus.
Say to me if am i wrong.
Reading what you been wrote here, the both domains needs an ssl sig to be trusted? And the fix the “htxps://d335luupugsy2.cloudfront.net/http://www.asseinfo.com.br/wp-content/themes/asseinfo/js/loader-scripts/6901f2e6-ce31-4235-9af7-012e51dd524a-loader.js” content?
If am i saying any nonsense thing, sorry, my english not so good. Haha
Hello HonzaZ, Lisandro and Polunus
I’m from ISA devel team, with Houshi and, for a while, I got the ISA vs Avast saga.
After reading all your support in this subject (tanks for that), we found that the best solution is the digital signature, but the main question here is, “is this the definitive solution?”. As I couldn’t answer this question to the whole team, I’m here to respectfully make YOU this question.
So, If we sign our products (ISA.EXE and ISA_PDV.exe), it will be the definitive solution? Remembering that we release new versions of those products at least once a week and sometimes twice or three times a week, and every time our costumers update it, we have Avast block.
Thank you again for all your help, and I’ll wait for your answer, to then acquire a digsig properly.
Hi Renato,
Unfortunatelly, digsig is not a silver bullet. What sometimes happens is that digital signatures get stolen (or the original issuer starts signing pup/adware/malware as well as clean files), so we cannot trust them all the way. That being said, they are still a very strong indicator that the signed files are not malicious.
So is it possible that Avast recognize my digsigned app as non-malicious and stop to bother me? Or the best chance is that I may sign my app in vain?
What I want to mean is that I’m worried about the possiblility of spend money (Signature, developpers, support) trying to solve a problem, and in the end find out that it was not solved.
I cannot promise you anything - digitally signed files are not “magically considered clean for ever without any exception”. What I am saying is that digsig helps with preventing false positives greatly.
Also, I think that if your PE files are to be used by more than 10 people, digitally signing them is considered best practice anyway.
At first, I’d like to thank you for all your support.
I think, based in all that was written before, that the best solution (but not the perfect one) is digitally sign our files AND our webservice. With those actions we may minimize a lot those detections from Avast.
But a new information was introduced yesterday from one of our support team member. He disabled the Avast CyberCapture, and all the problems stopped. I don’t even know if this is a real solution, or if CyberCapture is the “vilain”, but the fact is that, disabling it, the false positives stopped. I undestand also that this cannot be the definitive solution beacuse I’m allowing that real unknown malwares to be undetected too, but until we find a better solution, we are disabling CyberCapture from our customers computer. If you have any information you think to be relevant about this subject, please, let me know.
As I told you before, I’ll sugest our team to take those two actions: Sign our files, and sign with SSL our webservice. As soon as possible I’ll tell you the result of those actions.
Thank you all once again.
Digsig files = way to go, will help with false positives.
SSL on your domain = way to go, but (as I said earlier) it will probably not help with false positives at all.
This doesn’t make any sense. CyberCapture only acts as one of the shields. A user, without risking being infected, might opt to send the file to us for analysis, then after we are done, we send back the result. The fact that you disable CC only means that you leave the user unprotected from other threats, but should not help with false positives, as we use the same algorithms to decide if the file is malicious or not for all files, no matter if they went through CC or not. I would say this (not getting FP on the file when CC was disabled) was pure luck, and I do not see any reasonable reason why it would help.
Also, I already said (Feb 15th) that I added isaerp.com.br to clean CC class, which means all files downloaded from this domain should be classified as clean (unless there are other indicators indicating otherwise). If you have a file that is detected by CC, post its sha256 here and I will take a look at it.
Well, I searched some information about CyberCapture before write you that last post. It didn’t make sense for me too. For this reason I wrote that, to be sure I was not crazy. So, for a while, lets discard the possibility of CyberCapture be the “bad guy”.
I’ll keep my first speach: I’ll digitally sign my files.
After this, I’ll tell you the results, OK?
Thank you again for all the support and patience.
Best Regards.
Cool! Let me know your digsig hash when you are ready signing the files (or send me one of the files that are signed) and I will make sure to add it to cleanset.