0xDEADBEEF
-
Posts
361 -
Joined
-
Days Won
3
Posts posted by 0xDEADBEEF
-
-
SHA256: 67589ebe860dee5fcd8927d62c7085a23ddaca517657e6bc9e76225df2097544
SHA256: ef9d512a9fb0c93bfda9d6427690c0880f500968798411f85b825c085df1de3b
It is detected as potentially unwanted on VT. However, it seems the Chinese version of ESET doesn't flag FlyStudio Packed detection even with PUA on. Since FlyStudio Packed-type malware is very popular in China, this is considered a miss
I've seen many Chinese-born FlyStudio malware. I am not sure if ESET will add a secondary detection on those malware even with this PUA detection. If ESET doesn't, then Chinese version ESET might miss many samples.
-
On 8/28/2017 at 7:57 AM, itman said:
Since you let the malware run with admin privileges, it literally could have done anything.
One example if employed by the malware is PsExec which needs to run at admin level. With PsExec, credentials can be modified and malware privilege escalated to System level. At that point, the malware can do anything.
The important thing to note about PsExec is it is a valid Microsoft code signed utility process. As such it will not be detected by any AV as malware.
Yep, continue improving my auto exec and submission system while tightening the control.. I also added some yara rules to scan the samples as a reference.
Recently I didn't find any missed samples. Good job ESET
-
On 8/28/2017 at 8:00 AM, Peter Randziak said:
Hello @0xDEADBEEF ,
so far I got only positive feedback on this i.e. after using the utility and system reboot, the issue was solved so in your case it is probably something different.
Can you please try the utility once more from the elevated command line, set your system to be able to generate full manual memory dump, reboot the system and if you see the non-paged pool in GiBs again, get the full memory dump, pack it, upload it online and send me a download link so we can check it.
Regards, P.R.
We tried again but it still doesn't help. I've sent you the download link of the dump through private message.
-
The result from SE Lab is a bit counter-intuitive. e.g. Norton generally generates many of FPs in real life use (not only I myself, but also the case from the feedback of many other people). This makes me wondering what their sampling method and sample size are.
This also reminds me of AVC's malware protection test. Their test shows that ESET's score is identical before/after execution (so no dynamic detection, unless they also count AMS into "scan"). This strongly implies that their testing samples are too old to reflect the real-world situation.
-
On 8/26/2017 at 1:26 PM, itman said:
@0xDEADBEEF, here's another one that Eset detected earlier this month using the same Win32/Filecoder.NMK signature:
SHA256: 1c0ffdaddec1eca9a9a5ef5192151dbce8ccd8e31a84c51d70f5a5c64f07a363
This again leads me to believe your current sample was delivered via some type of obfuscated script.
I've been offline for a while to debug that sample in my testing env, because my cuckoo failed to capture its behaviors. And later I realized it is crashing most of the processes (including cuckoo's agent) when doing manual check, indeed an interesting one. Looking forward to seeing that cuckoo will gradually move from R3 hooks to more reliable ones
-
37 minutes ago, itman said:
Also check your permissions on C:\MSOCache. Your Eset event log indicates that the ransomware was running out of that directory. On my Win 10 build, files within that directory are read only. Also anything in that directory appears to be related to Microsoft software installations e.g. MS Office.
FYI -
https://www.tenforums.com/performance-maintenance/43220-msocache.html
The test machine for that screenshot is a bit special (UAC disabled and admin granted, similar to a typical Cuckoo machine setup). Will check on another machine.
Usually when I see ESET popping up tens of messages, I know it fails to stop a ransomware (those messages are usually for some ransom notes). This one is, however, a bit more interesting. But I haven't got a time to do any behavioral analysis on it yet.
-
6 minutes ago, itman said:
This one appears to be hijacking a valid 32 bit .dll, cl3d32.dll, which is located in the SysWOW64 directory. Appears ransomware .exe is 32 bit.
Interesting. I will grant the sample to run for a longer time in the virtual env and see if I can observe that
-
1 minute ago, itman said:
Play with malware and sooner or later, you'll get burnt.
Trying my best to build isolated environment, including my physical testbed
-
SHA256: 8b16103d8019fae324e7f6f9409a612b0b24a90177e413fe3d4101fbabe61b47
filecoder, my test machine is encrypted with latest eset (15975). (it is detecting filecoder.nmk, but files are encrypted anyway)
And it bypassed my non-physical testing machine
AND other vendors:
-
On 8/24/2017 at 1:31 AM, Peter Randziak said:
Hello all,
In case you have pool leak please try to run EpfwWfpRegV10.1.3.exe /unreg from an elevated command line and reboot the system. The utility is available at: hxxp://ftp.nod.sk/~randziak/EpfwWfpRegV10.1.3.exe
Please let us know if the leaks are fixed after using the utility.
@elpamyelhsa thank you for the provided dump file.
Thank you, P.R.
No, the issue still persists
-
SHA256: 1c7245076c34455fb532e5cb5fef71df7b083ba44cb89f37f31b054f4446ce81 (putty connect to some host
)
SHA256: 222cfaa71487f5b0b9f5fbaaf710482f99647f90eb68c4814a6f1f18e8f14f2f (delay the execution for some minutes, the downloaded filecoder is detected)
-
The person who originally reported this issue provided the dump: https://1drv.ms/u/s!AkO8JVZQ3apzg1lBNYrnDzsah7PI
Hopefully ESET could fix this issue soon. Please let me know if more info is needed.
-
8 hours ago, Marcos said:
It seems to be a new TrickBot blocked in LiveGrid about 9 hours ago and the detection added in update 15954 released about 3 hours ago. If malware is already running in memory and we detect it, the process is either terminated or suspended. That said, even if you see a malicious process among running processes, it may be in suspended state and do nothing. The computer should be restarted to finish cleaning.
Cool! I observed the same situation in the first run. Perhaps in the second reboot, ESET receives 15954 and directly detected the exe itself.
-
SHA256: 9c96696aef7f0baeecd8e52d7075928e886bd2ff2f90d7bd2d928245637f55c9
ESET blocks some threats, but the original executable remains persistent in the machine
and therefore the memory
EDIT: Hmm interesting, after I reverted the snapshot and tested again, ESET detects it. Alright this doesn't count.
-
10 minutes ago, Marcos said:
Detected and blocked by LiveGrid
It's Filecoder.Locky. We'll need to investigate what happened during replication as it should have been blocked by LiveGrid hours ago. Strange that almost no other big AV vendors detect it yet.
That's indeed strange. I tested the sample 1 hour ago with latest ESET and LiveGrid enabled, but I didn't get any warnings from ESET, even after the execution (do I expect to see ESET reporting "Suspicious Object" if it is by LiveGrid?)
-
14 minutes ago, itman said:
This appears to be ransomware just discovered this morning. Appears to be delivered via a zip file. Most likely an e-mail attachment.
Also Eset might already be blocking this by blacklist. Only way to know for sure is run the sample w/Eset installed in a VM. This also might not work since many ransomware are now employing VM and sandbox detection methods and refuse to run.
Nope. ESET is silent
I used a cloaked VM anyway
-
Isn't relying on adblock for safety similar to relying on some AVs which purely based on hash/fuzzy-hash blacklisting?
Besides, simple anti-adblock tricks and some social engineering can easily bypass this, if the user is not "cautious enough"
-
SHA256: 3b60fde281d91cc3e7ea3e343ee5b13a31def564903c0136ae928f70e25c3c02
Some sort of injector?
-
11 hours ago, TomFace said:
Shouldn't this be submitted to samples@eset .com? There is an established procedure in place.
I usually submit by the right click menu. I post here because I never get response from ESET and sometimes I am curious if the sample is worth detecting.
-
1 hour ago, itman said:
I do see a pattern forming though. Suspect a lot of these AI/Next solutions along w/Avast-AVG and a few others are perhaps "plugged-in" to Microsoft's Azure AI servers. So when it detects, they all post a positive hit.
No, early first seen date doesn't necessarily mean it is benign. The sample I provided is very likely to be malicious before it is expired (share advertisement)
In case if you are interested in this family, here is a translated version https://translate.google.com/translate?hl=en&sl=zh-CN&u=hxxp://www.freebuf.com/articles/system/144525.html&prev=search
-
6 minutes ago, Marcos said:
it's a one month old file, almost no big vendor detects it. Resembles DealPly PUA. Drops a batch file that deletes the exe. The file was passed for further analysis to find out if it's worth detection.
thx for the reply. It should be an expired one (connecting to a dead host). But since ESET didn't detect it I chose to put it here (another one from the same source (type) is detected as Generic.IXMGFLM, maybe currently it is not categorized into some family?)
-
SHA256: cf9a800c3b009abed68a684aaf2f8cad7793b930fc323a2a2231edd5e8c3747b
-
1 hour ago, itman said:
My best guess is it is benign but performs highly suspect activities.
Yes, I had my own cuckoo run this sample and was not sure about this particular one after looking at the report. I tend to feel that it is an FP
-
9 hours ago, Marcos said:
Which one(s)? I'm eager to check them closer. Also are you talking about executables? Because the situation is a bit different if, for instance, a script malware (downloader) is not detected but the payload is so in the end the computer doesn't get infected.
SHA256: 8de12700ad1cb6b9573bd0bf4cfa8d17c6370bec30576262ced4dd3916f4c9ab
is this malicious?
Interesting Samples
in Malware Finding and Cleaning
Posted
SHA256: a06af1ebeff4795126cbe2765954bbe177b7a34ba11e84631b347e79ef23f6f0