Jump to content

0xDEADBEEF

Most Valued Members
  • Content Count

    344
  • Joined

  • Days Won

    3

0xDEADBEEF last won the day on June 5 2018

0xDEADBEEF had the most liked content!

2 Followers

Profile Information

  • Location
    USA

Recent Profile Visitors

1,603 profile views
  1. hmmm I feel like this is a false positive
  2. I think the sample I provided (not the one in this thread) is not even obfuscated. I don't know how the scanner actually does signature matching with text files but it is definitely not only the obfuscation's fault. Anyway I sincerely hope that this could be addressed in an elegant way in the near future
  3. I am not sure if the detection from realtime scanner utilizes the AMSI or not. AMSI to me is like AMS to PE scanning, which will only be triggered upon execution. I think the core problem here is to detect what type of script the txt file is in (e.g. js, powershell, or anything else). And this may be non trivial. Apparently there are samples which can even trick AMSI, however here with unobfuscated code the only possible explanation is that the scanner doesn't even bother to check if txt file is actually js or something else. This is what I am thinking The subtle thing here is that if people want to optimize the realtime scan performance with aggressive caching, they had better make sure all possible ways of execution can be guarded to avoid leakage. For example, what if there are 3rd party interpreters that is not going through AMSI? In the old days, people have tried to use some installer's interpreter to bypass the "guards". There are many possibilities here. I was thinking about this before I start this thread. However, it is not an elegant solution, and there may be other possibilities to bypass with similar principles..
  4. https://pandownload.com This has been blocked for quite some time while most other vendors are all showing clean. Is there a reason behind this detection?
  5. even in 1903 this is the case. So apparently AMSI is working fine in 1903. This is the most trivial case and I'd be surprised if this can bypass the protection
  6. for powershell script, I have already given you the answer in the prev replies: Of course I said this after doing the actual experiment. However, it is not always the case (I can enumerate at least 2 other possible ways but I've yet tested them)
  7. See my PM. I'm not going to discuss it here before they say it is expected and acceptable
  8. However in my test this is not the case. My test env is Win10 1903 so AMSI is enabled. I did no source code change to the payload. What's worth noting is that I cannot reproduce the case on EES. Only EIS has such issue. I also uploaded the sample to a webhost to simulate the user download scenario with a different hash, still no luck...
  9. @Marcos I've PM-ed you the PoC sample. Could you evaluate if it is indeed a vulnerability?
  10. Nope, I think I've found some issues already. But will not post here for now...
  11. Sometimes I got batches of samples (in zip) for analysis. I agree that it is slightly different from web download distribution. Anyway, I've recorded the case I was mentioning here: https://imgur.com/a/hGcPdsl Note the two zip files have exactly the same file, except that the one with _ps1 contains .ps1 extension
  12. This is very weird. I am running on latest EES with all settings set to default (except for the exclusion list). This has been reproduced on more than one machines on my side (I've not tested EIS but itman confirmed it) This is not the first time I've experienced this. Previously another javascript malware sample has the same issue (it lost its .js extension hence ESET on-demand didn't detect it, though it could if the extension was correct) Other users are welcome to try and see if this is reproduce-able on their side, however I don't think I can provide a sample link for them to download here... Another thing to note is that even though such case may "slip through" the realtime protection, when actually executing it, the engine will anyway inspect it again. So if this is indeed something unexpected, at least it is not something really bad so far. I will try some other types of scripts and see how it goes.
  13. yes. So if the script is landed on disk as .txt file for the first time, the realtime protection won't detect it, neither does on-demand scan. If I later rename it to .ps1 the on-demand scan still does not detect it. However if the script is landed on disk as .ps1 file for the first time, the realtime protection will immediately detect and quarantine it. It is very likely that in the first case the file is cached as "benign" due to .txt extension initially, and later got exempted from being scanned again by the right-click scanner even with .ps1 extension. The attached sample's password is "infected" sample.zip
  14. Something I've noticed is that seems ESET is spending a huge effort since last year to optimize the real-time monitoring performance. A side indicator is that its performance score in AV-TEST has improved significantly (5.5/6.0 recently in business test, in the past it was usually 3~4 out of 6.0 for home products). I can feel the real-time monitoring has become less sensitive (not in a bad way, though) Still I was wondering why the scanner is detecting some files solely by extension. Though detecting a text file and infer its language/content may not be straightforward, many other vendors do. I am not seeing a vulnerability in doing so, but sometimes it is a bit confusing
×
×
  • Create New...