mcrouse 1 Posted July 6, 2020 Share Posted July 6, 2020 I had a workstation which was infected with Trickbot and Kryptik. ESET found and cleaned several items related to this including a malicious Kryptik DLL and .MGB file. It also remediated malicious svchost and wermgr.exe processes which is consistent with Trickbot IOC's. However, it is still detecting Trickbot in subsequent scans. It does not detect any malicious DLLs or processes anymore. Only a single file:/// from the ERAAgent process. The following is the detection detail: Hash Name Win64/TrickBot.BU Uniform Resource Identifier (URI) file:/// Process name C:\Program Files\ESET\RemoteAdministrator\Agent\ERAAgent.exe Is this just picking up some sort of artifact or is this a persistant threat that ESET is unable to clean. I'm about to image the machine but thought i'd check and see if this has been seen before. Thanks! Link to comment Share on other sites More sharing options...
Administrators Marcos 4,713 Posted July 6, 2020 Administrators Share Posted July 6, 2020 Please provide logs collected from the machine with ESET Log Collector. Link to comment Share on other sites More sharing options...
itman 1,542 Posted July 6, 2020 Share Posted July 6, 2020 Trickbot is known for creating a scheduled task for persistence. Task names line "Bot", etc.. Link to comment Share on other sites More sharing options...
mcrouse 1 Posted July 6, 2020 Author Share Posted July 6, 2020 Good point, I checked the scheduled tasks and didn't see anything out of the ordinary. I'll be collecting logs and posting them tomorrow when the user is back in the office. In the meantime, the machine is isolated and off the network. Thanks guys! Link to comment Share on other sites More sharing options...
itman 1,542 Posted July 6, 2020 Share Posted July 6, 2020 (edited) As far as the file:/// notation is concerned: Quote The file: URL scheme refers to a file on the client machine. There is no hostname in the file: scheme; you just provide the path of the file. So, the file on your local machine would be file:///~User/2ndFile.html. Notice the three slashes; the hostname part of the URL is empty, so the slash at the beginning of the path immediately follows the double slash at the beginning of the URL. You will also need to expand the user's path; ~ does no expand in a file: URL. So you would need file:///home/User/2ndFile.html (on most Unixes), file:///Users/User/2ndFile.html (on Mac OS X), or file:///C:/Users/User/2ndFile.html (on Windows). Many browsers, for security reasons, do not allow linking from a file that is loaded from a server to a local file. So, you may not be able to do this from a page loaded via HTTP; you may only be able to link to file: URLs from other local pages. https://stackoverflow.com/questions/12711584/how-to-specify-a-local-file-within-html-using-the-file-scheme Edited July 6, 2020 by itman Link to comment Share on other sites More sharing options...
mcrouse 1 Posted July 7, 2020 Author Share Posted July 7, 2020 Logs attached. It looks like the infection was caused by a freeware application called ArtPress that the user had downloaded. Checking the task scheduler today, I noticed a task set to run everytime the user logged on which I deleted. My most recent ESET scan showed 0 detections but hopefully someone can confirm via the logs ees_logs.zip Link to comment Share on other sites More sharing options...
Administrators Marcos 4,713 Posted July 7, 2020 Administrators Share Posted July 7, 2020 Please drop me a message with the file C:\Users\ccasimir\AppData\Roaming\ArtPress\nbUQEZPGUlb.mgb, if exists. Most likely it does't exist since no details about it were in the logs. Run the system Scheduler and remove the task "ArtPress free Windows application". Link to comment Share on other sites More sharing options...
mcrouse 1 Posted July 7, 2020 Author Share Posted July 7, 2020 Hey Marcos, tt doesn't exist/was deleted. There was also a DLL in that same folder which was deleted it looks like. That ArtPress task was deleted from the system scheduler. Thank you for taking a look at those logs. Based on the info provided and the fact that scans are no longer detecting anything, do think the issue has been remediated? or should I still reimage the machine? Link to comment Share on other sites More sharing options...
Administrators Marcos 4,713 Posted July 7, 2020 Administrators Share Posted July 7, 2020 Was that dll really detected? In your logs the malware was detected in running processes but not in a dll. Link to comment Share on other sites More sharing options...
mcrouse 1 Posted July 7, 2020 Author Share Posted July 7, 2020 (edited) Yeah, in a prior scan the following was detected and cleaned : file:///C:/eNNzmNj/wLrKvzZ/UQEZPGU.dll edit: It was not in the same folder but related to the initial infection I believe Edited July 7, 2020 by mcrouse Link to comment Share on other sites More sharing options...
Administrators Marcos 4,713 Posted July 7, 2020 Administrators Share Posted July 7, 2020 Exactly. That dll was found suspicious and was submitted: 3. 7. 2020 18:54:51 C:\eNNzmNj\wLrKvzZ\UQEZPGU.dll 438272 Executable Automatic LiveGrid® It's a good practice to check also Sent files logs for suspicious files if you have a problem cleaning a threat. Link to comment Share on other sites More sharing options...
mcrouse 1 Posted July 7, 2020 Author Share Posted July 7, 2020 Ahh ok, I did not think to check that log and was going off of what was reported to the ESMC. Thanks for the heads up on that Link to comment Share on other sites More sharing options...
itman 1,542 Posted July 7, 2020 Share Posted July 7, 2020 Unfortunately,you deleted the scheduled task rather than disabling it. It would have been beneficial to have examined what that task was running; possibly a script but could have been a number of things, that recreated the Trickbot components at boot time. As it stands now, that startup run component is still on the device. It is now hopefully "nuetered" and should do no futher damage. Link to comment Share on other sites More sharing options...
Recommended Posts