Once a breach appears, your next thought can be to remove all suspicious files and forget about the problem. But it can actually make the situation worse as all valuable information will be gone. And you will definitely need it: to identify where the attack happened and work out a strategy to stop future breaches.

Do the research and retrieve data

When in a shift for your Incident Response role, you could be notified by the SOC analysts team that for a couple of endpoints a connection to a known C2C server has been detected, and the IP address drives to Agent Tesla trojan.

One of the first things you can do for giving more context to the alert escalated by the SOC team is to search the IOC matched against the Threat Intelligence sources you can rely on, and one of them is for sure public tasks by ANY.RUN.

From the recent tasks submission list, you can click on the filter symbol near the search textbox in the upper-right corner of the page:

And then type the IP address detected from the alert in the Context -> IP address text box.

Then, all the samples that have been analyzed within the public access rights, and for which that IP address has been detected in the network communications, will be listed and you can explore them one by one.

While inspecting samples that are related to the IOC you are dealing with, you can leverage one of the best features of ANY.RUN – the Process Graph (you can find it in the upper right corner in the general pane), and you realize that the first action that this malware family does is gaining persistence through a scheduled task job as described in the ATT&CK MATRIX as TA0003 Persistence – T1053 Scheduled Task/Job – T1053.005 Scheduled Task.

In this example we see that the malware add a Scheduled Task with the name “Updates\VXEYaEBemoZ” using the following command and a dropped XML as a definition:

“C:\Windows\System32\schtasks.exe” /Create /TN “Updates\VXEYaEBemoZ” /XML “C:\Users\admin\AppData\Local\Temp\tmpF7CF.tmp”

What we can do now is to read the contents of the XML file used as a definition for the schedule, and retrieve, for example, the triggers and the command executed. For doing so, we can again leverage the power of ANY.RUN features, in this case, the files modification tracing. We can achieve the result by clicking on the file’s icon in the pane  under the video history section where the analysis processing can be played back (note that the default focus is on HTTP requests):

Switching to files view we can see the list of all files created (usually by a dropper or by a downloader) during the sample execution, and of course also our scheduled task definition XML.

We can now click on the Content column (the rightmost) for the selected row, and a new window opens showing the content of the file, with a lot of pieces of information about the artifact itself and some shortcuts for doing a lookup in VirusTotal or submitting the new file to a standalone dedicated analysis session.

Also, we have a preview in ASCII of the file, from which we are able to retrieve our information about the scheduled task.

Since the trigger of the task is to be run at logon, we won’t see it executed in the sandbox until the next user logon, that is not (actually) possible. Luckily, with the interactive capabilities of ANY.RUN, we can rerun the analysis, open the Scheduled Task management console and run it on demand.

Note: it is possible to do a logoff-logon cycle since this operation breaks the communication between the guest and the sandbox controller.

Interact with the task safely 

So, let’s run the analysis again and interact with the Scheduled Task. From the details of the schtasks.exe process, we can see that the task is registered at about 37 seconds after the analysis start.

So, the rerun should consider enough time for the task to be created and the operation to open the console and run it; a timeout of 120 seconds could be enough for the purpose, and this is an option we can choose from the submission form.

Once the analysis begins, on the right of the window there is the processes monitoring section, where processes appear as soon as they are created. Once we see the schtasks.exe popping out, the Scheduled Task has been created, and then we can open the console and run it manually.

After the manual execution, we can see that the persisted process executes the very same sample and behavior of the infecting parent.

At this point, we have a broad picture of what we need to search for identifying the spread of this specific malware family in our controlled network and can hunt for other clients that have been infected but for some reason, the detection has been bypassed; this could be done via performing remote triage sessions over our assets, for example with PowerShell:

In conclusion, the features of ANY.RUN online sandbox and the wide range of intelligence gathered in the time with public submission could help Incident Response teams in being quicker with the triaging and containment, and at the same time, they allow to play with dangerous pieces of code in a controlled and traced environment.

Personal Notes:

Hash: 850c25e23cc582bad58318fb70772023c21b36fcb50966a36b659e7199f4cc70

Sample: https://app.any.run/tasks/1c6adef6-0ac5-456c-b2e3-e8a559562cd3/