Jump to content

Trickbot detection with ERAagent process


Recommended Posts

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 post
Share on other sites
  • Administrators

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

Link to post
Share on other sites

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

Link to post
Share on other sites

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 post
Share on other sites

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

Link to post
Share on other sites

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 post
Share on other sites
  • Administrators

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 post
Share on other sites

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 post
Share on other sites
  • Administrators

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

Link to post
Share on other sites

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

 

Link to post
Share on other sites
  • Administrators

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 post
Share on other sites

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 post
Share on other sites

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 post
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...