Jump to content
mcrouse

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!

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


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!

Share this post


Link to post
Share on other sites
Posted (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 by itman

Share this post


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

Share this post


Link to post
Share on other sites

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

Share this post


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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Posted (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 by mcrouse

Share this post


Link to post
Share on other sites

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.

Share this post


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

Share this post


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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...