Trickbot detection with ERAagent process

[mcrouse 1]

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!

[Marcos 5,070]

Please provide logs collected from the machine with ESET Log Collector.

[itman 1,659]

Trickbot is known for creating a scheduled task for persistence. Task names line "Bot", etc..

[mcrouse 1]

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!

[itman 1,659]

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

[mcrouse 1]

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

[Marcos 5,070]

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".

[mcrouse 1]

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?

[Marcos 5,070]

Was that dll really detected? In your logs the malware was detected in running processes but not in a dll.

[mcrouse 1]

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

[Marcos 5,070]

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.

[mcrouse 1]

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

[itman 1,659]

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.