4.1. License Management¶
Login to ASGARD, navigate to
Upload ASGARD Management Center License and upload a valid license.
After uploading, the license details are displayed.
4.2. System Status¶
The initial system status page provides a summary of the most important system components.
It also includes the current resource consumption (disk, CPU and memory) and lists the currently installed ASGARD software version along with available versions of THOR. Additionally, the connection status to the update servers, MASTER ASGARD and Cockpit are shown with a graph that shows asset connections and asset streams.
The THOR version numbers may be missing in a new installation. THOR is not included in the installed packages. THOR is downloaded automatically after the installation and should show up not later than one hour after installation.
The logs section shows the latest and most relevant logs. Complete logs can be found at
4.3. ASGARD Agent Deployment¶
In order to register a new endpoint to the ASGARD Management Center, download and install the ASGARD agent on the system you want to register.
The ASGARD agent can be downloaded from ASGARD directly through the button
Download ASGARD Agent. A list of available agents for various operating systems appears.
After installation, the endpoints will connect to ASGARD, register automatically and appear in the Asset Management Section in the tab
Requests. Please allow two or three minutes for systems to show up. The agents use the hostname to connect to ASGARD, ensure that your endpoints can resolve and reach the ASGARD hostname.
In the requests tab, select the agents you want ASGARD to manage and click
Accept. After that, the endpoint shows up in the asset tab and is now ready to be managed or scanned.
A registered agent will poll to the ASGARD Management Center at a given interval between 10 seconds and 600 seconds – depending on the number of connected endpoints (see chapter 6.1 Performance Tuning for details). If ASGARD has scheduled a task for the endpoint (for example: run THOR scan) it will be executed directly after the poll.
4.4. Asset Management¶
Management of all endpoints registered with ASGARD can be performed in Asset Management. The assets will be presented as a table with an individual ASGARD ID, their IP addresses and host names.
By clicking the control buttons in the Actions column, you can start a new scan, run a response playbook, open a command line or switch the endpoints ping rate to a few seconds instead of a maximum of 10 minutes.
- The internal ping between the ASGARD agent and ASGARD is based on HTTPS not ICMP
- Depending on the user's role some of the control buttons may be disabled
4.4.2. Column Visibility¶
Users can select various columns and adjust their view according to their needs.
4.4.3. Asset Labels¶
Labels are used to group assets. These groups can then be used in scans or tasks.
You can add multiple labels to an asset or a group of assets. This is done by selecting the particular assets in the left column, typing the label name (e.g. New_Label) and clicking the blue
Add Labels button.
Don't use labels with white space characters as it could cause issues in syncs with Analysis Cockpit, exports / imports or other underlying legacy functions.
In order to remove labels, select your assets, click the yellow
Remove Labels button and type the name of the label you want to remove for these assets.
The asset management section has extensive filtering capabilities, e.g. it is easy to select only Linux endpoints that have been online today and have a particular label assigned.
220.127.116.11. Export Asset List¶
The Import/Export Section allows you to export your assets to a .csv file.
18.104.22.168. Import Labels¶
The import function allows you to add or remove labels on assets based on columns in that CSV file.
The import function processes the values in the columns
Add Labels ... and
Remove Labels ... only. In order to change labels, use the already exported list, add values in these columns and re-import it by using the
Apply Labels from CSV button. Separate multiple labels with comma. Leading or ending white space characters will be stripped from the labels.
4.5. Scan Control¶
4.5.1. Managing Scan Templates¶
Scan templates are the most convenient way to make use of THOR's rich set of scan options. Starting with ASGARD 1.10., it is possible to define scan parameters for THOR 10 and store them in different templates for later use in single scans and grouped scans.
Imagine you want to use dedicated scan options for different system groups (e.g. Linux Servers, Domain Controllers, Workstations, etc.) and make sure to use exactly the same set of scan options every time you scan a particular group of systems. With ASGARD you can now add a scan template for every group.
A popular use case for scan templates is providing additional resource control – for example telling THOR to set the lowest process priority for itself and never use more that 50% of a single CPU.
Please keep in mind, that we have already optimized THOR to use the most relevant scan options for a particular system (based on type, numbers of CPUs and system resources) and a comprehensive resource control is enabled by default.
For more details please refer to the THOR manual. Only use the scan templates if you want to deviate from the default for a reason.
Scan templates are protected from being modified by ASGARD users without the "Manage Scan Templates" - permission and can also be restricted from being used by ASGARD users in case the flag "ForceStandardArgs" is set for this user. (see user management section for details).
In order to create a scan template, navigate to "Scan Control" > "Scan Templates" and click the "Add Scan Template" button. The "Add Scan Template" dialogue appears. After choosing a scanner you will find the most frequently used options on the top of this page in the "Favorite Flags" category. You can view all THOR options by clicking on the other categories.
After choosing a scanner you will find the most frequently used options on the top of this page in the "Favorite Flags" category. View all THOR options by clicking on the other categories. By clicking on the star symbols you can also edit your favorites.
By checking the "Default" box, you can make this scan template the default template for every new scan. Not Checking the "Enforce" box restricts this scan template from being used by any ASGARD user with the "ForceStandardArgs" restriction set. After clicking the "Add" button on the bottom of the template page, an overview of all existing scan templates is shown.
By clicking the
Import Scan Template button and choosing a file you can import a scan template.
4.5.2. Scan a Single System¶
22.214.171.124. Create a Single Scan¶
The creation of a scan is performed within the Asset Management. There is a button for each asset to create a new scan and to show all past scans.
Just click on the "THOR" button in the Action column in the Asset Management view.
Within this form, you can choose the max. runtime, module, scanner, scan flags, signatures and template can be selected.
After the desired parameters have been set, the scan can be started by clicking the
Add Task button.
126.96.36.199. Stopping a Single Scan¶
To stop a single scan, navigate to the "Single Scans" tab in Scan Control section and click the "stop" (square) button for the scan you want to stop.
188.8.131.52. Download Scan Results¶
After the scan completion, you can download the scan results via the download button in the actions column.
The download button has the following options:
- Download THOR Log (the text log file)
- Download HTML Report (as *.gz compressed file; available for successful scans only)
- Show HTML Report (opens another tab with the HTML report)
4.5.3. Scan Groups of Systems¶
184.108.40.206. Create Grouped Scans¶
A scan for a group of systems can be created in the "Scan Control > Group Scans" tab. Click the
Add Group Scan button in the upper right corner.
As with the single scans, various parameters can be set. Aside from the already mentioned parameters, the following parameters can be set:
Freely selectable name for the group scan.
Here you can define which assets will be affected by the group scan. In case more than one label is chosen: An asset must have at least one chosen label attached to it to be affected by the scan. If no label is selected, all known assets will be scanned.
ASGARD will not send additional scans to the agents when the client limit is reached. Therefore you need to set a limit higher than the number of hosts you want to scan. If you are using MASTER ASGARD, this limit is applied on each single selected ASGARD.
The number of scans per minute that a scan should run. This is where the network load can be controlled. Additionally, it is recommended to use this parameter in virtualized and oversubscribed environments in order to limit the number of parallel scans on your endpoints.
After this time frame, no scan orders will be issued to the connected agents.
Select a date for a scheduled start of the scan.
After the group scan has been saved or saved and started, you will automatically be forwarded to the list of grouped scans.
220.127.116.11. List of all Group Scans¶
The list of all group scans contains, among other items, the unique Scan-ID and the name.
In addition, information can be found about the chosen scanner, the chosen parameters, the start and completion times and the affected assets (defined by labels). Additional columns can be added by clicking on "Column Visibility".
The Status field can have the following values:
Started: Scan is started, ASGARD will issue scans with the given parameters
Stopped: No additional scan jobs are being issued. All single scans that are currently running will continue to do so.
Completed: The group scan is completed. No further scan jobs will be issued.
18.104.22.168. Starting a Group Scan¶
A group scan can be started by clicking on the "play" button in the "Actions" column of a group scan. Subsequently, the scan will be listed as "Started".
22.214.171.124. Starting a Scheduled Group Scan¶
The Scheduled Group Scan section shows all scans that are to run on a frequent basis along with their periodicity. All group scans that have been started through the scheduler will show up on top of the Group Scan section the moment they are started. New scheduled tasks can be created by clicking the
Add Scheduled Group Scan button.
126.96.36.199. Details of a Group Scan¶
Further information about a group scan can be observed from the detail page of the group scan. Click the scan you are interested in and the details section will appear.
Aside from information about the group scan in the "Details" tab, there is a graph that shows the number of assets started and how many assets have already completed the scan in the "Charts" tab. In the "Tasks" tab you get information about the scanned assets.
4.5.4. Integrating Custom IOCs¶
The tab "IOC management" gives you the opportunity to easily integrate custom signatures into your scans.
In order to create your own custom IOC Group, navigate to
Scan Control >
IOC Management >
Add IOC Group in the upper right corner. Select a name, a description and a ruleset for your IOC Group.
To add IOCs to this group, just click the entry in the table and two blue buttons will show up. You can click the
Import IOCs button to import your own signatures in any of THOR’s IOC formats (e.g. files for keyword IOCs, YARA Files and SIGMA files). Refer to the
THOR manual (custom signatures) for a complete list and file formats. Browse to the file you want to add and click upload. This adds your IOC file to the default ruleset.
However, you can also click the
Add IOC(s) button to add some IOCs manually. Select the type, score and description, enter some values and click the
Add IOC button.
You can add those IOC Groups to Rulesets which can be generated in the
Scan Control >
IOC Management >
Ruleset tab by clicking the
Add Ruleset button in the upper right corner. Select name and description and click the
Add Ruleset button.
After that click on an entry in the table to expand this entry. There you get information about all IOC Groups which have been added to this ruleset. Additionally you can add or remove IOC Groups by clicking one of the three buttons shown below.
Those rulesets can be selected in the "Custom Signature" field while creating a new scan job. If a ruleset is selected, the scan will include all custom IOCs included in IOC Groups which have been added to this ruleset. You can also select more than one ruleset.
Please note, ASGARD does not provide a syntax check for your IOC files. Should THOR be unable to parse your IOC files for the scan, THOR will skip the particular file with syntax issues and send an error message in the scan log. All other files with correct syntax will be used for scanning. THOR will report files that can be parsed and are used for scanning in the scan log.
4.5.5. Integrating IOCs through MISP¶
ASGARD provides an easy to use interface for integrating IOCs from a connected MISP into THOR scans. In order to add rules from a MISP, navigate to "Scan Control > MISP Signatures > Events", select the IOCs and add them to the desired ruleset by using the button in the upper right corner.
Contrary to the custom IOC handling, there is no default ruleset for MISP. You must create at least one ruleset (see tab "MISP Rulesets") before you can add MISP rules.
In order to create a ruleset, click
Add MISP Ruleset in the "Scan Control > MISP Signatures > Rulset" tab. Select a name and the type of IOCs you want to use in this ruleset. By default, all types are selected, but there may be reasons for deselecting certain categories. For example, filename IOCs tend to cause false positives and may be deselected for that reason. The picture below shows the dialogue for adding a MISP ruleset.
In order to use a MISP ruleset in a scan: Add the ruleset in the
MISP Signatures field when creating your scan.
4.6. Response Control¶
4.6.1. Opening a Remote Shell on an endpoint¶
In order to open a remote shell on an endpoint, open the Asset Management section and click the "command line" button in the Actions column.
Depending on your configuration it may take between 10 seconds and 10 minutes for the remote shell to open. Please note that all actions within the remote shell are recorded and can be audited. All shells open with root privileges or system privileges.
In order to replay a remote console session, navigate to Response Control, select the task that represents your session and click the play button.
ASGARD users can only see their own remote shell session. Only users with the RemoteConsoleProtocol permission are able to replay all sessions from all users.
4.6.2. Response Control with pre-defined playbooks¶
In addition to controlling THOR scans, ASGARD Management Center contains extensive response functions. Through ASGARD, you can start or stop processes, modify and delete files or registry entries, quarantine endpoints, collect triage packages and execute literally any command on connected systems. All with one click and executed on one endpoint or groups of endpoints.
It is also possible to download specific suspicious files. You can transfer a suspicious file to the ASGARD Management Center and analyze it in a Sandbox.
To execute a predefined response action on a single endpoint, navigate to the Asset Management view and click the "play" button in the Actions Column. This will lead you to a dialogue where you can select the desired action.
In this example, we collect a full triage package.
ASGARD ships with pre-defined playbooks for the following tasks:
- Collect full triage pack (Windows only)
- Isolate endpoint (Windows only)
- Collect system memory
- Collect file
- Collect directory
- Execute command and collect stdout and stderr
Nextron provides additional playbooks via ASGARD updates.
The collection of memory can set the systems under high load and impacts the systems response times during the transmission of collected files. Consider all settings carefully! Also be aware that memory dumps may fail due to kernel incompatibilities or conflicting security mechanisms. Memory dumps have been successfully tested on all supported Windows operating systems with various patch levels. The memory collection on Linux systems depends on kernel settings and loaded modules, thus we cannot guarantee a successful collection. Additionally, memory dumps require temporary free disk space on the system drive and consume a significant amount of disk space on ASGARD as well. The ASGARD agent checks if there is enough memory on the system drive and adds a 50% safety buffer. If there is not enough free disk space, the memory dump will fail.
4.6.3. Response Control for Groups of Systems¶
Response functions for groups of systems can be defined in the "Group Tasks"` tab or the "New Scheduled Group Task" tab.
4.6.4. Response Control with custom playbooks¶
You can add your own custom playbook by clicking the
Add Playbook button in the
"Response Control > Playbooks" tab.
This lets you define a name and a description for your playbook. After clicking the
Add Playbook button,
click on your new playbook and start adding steps by clicking the
Add Step button.
You can have up to 16 entries in each playbook that are executed in a row. Every entry can be either "download something from ASGARD to the endpoint", "execute a command line" or "Upload something from the endpoint to ASGARD". If you run a command line the stdout and stderr are reported back to ASGARD.
4.7. Service Control¶
Service Control is ASGARD's way of deploying real-time services on endpoints.
4.7.1. Service Controller Installation¶
To install asgard2-service-controller on an asset you need to install the asgard2-agent first. If you already have installed asgard2-agent on an asset and accepted it in ASGARD, you can use the "Install ASGARD Service Controller" playbook to deploy the service controller on an asset or you can manually download and execute the asgard2-service-controller installer from the ASGARD downloads page.
4.7.2. Service Controller Update¶
If an ASGARD update comes with a new service controller version, you need to update the service controller on the already rolled-out assets. You can do this using an "Update Agent" task. For a single asset the task can be run in
Asset Management >
Run Task (play button action) or analogous as a (scheduled) group task under
Response Control >
(Scheduled) Group Tasks >
Add (Scheduled) Group Task.
If you don't see the Update Agent module, you need to enable Show Advanced Tasks in
4.7.3. LogWatcher Service¶
The LogWatcher real-time service monitors the Windows Event Log using predefined rules in the Sigma format and creates an alert that is forwarded to ASGARD Analysis Cockpit if a match was found.
188.8.131.52. What is Sigma¶
From the project website:
Sigma is a generic and open signature format that allows you to describe relevant log events in a straightforward manner. The rule format is very flexible, easy to write and applicable to any type of log file. The main purpose of this project is to provide a structured form in which researchers or analysts can describe their once developed detection methods and make them shareable with others.
In order to make full use of ASGARD LogWatcher you need a Windows Audit Policy and Sysmon, both with a reasonable configuration, in place. We expect organizations to take care of providing a sane configuration by their own. This section helps in giving starting points, if needed.
184.108.40.206.1. Windows Audit Policy¶
The default audit policy of Windows is not suitable for security monitoring and needs to be configured. There are Microsoft recommendations available online.
Also auditing the command line for process creation events should be enabled. Documentation for that task is available here.
220.127.116.11.2. Sysmon Configuration Template¶
There are some best practise configurations available. See them as a good starting point to develop your own configuration. If you do not have a Sysmon configuration yet, there are several options we suggest:
- The Nextron Systems fork of SwiftOnSecurity's sysmon-config
- The SwiftOnSecurity sysmon-config
- Olaf Hartong's sysmon-modular
In general we suggest our own configuration, as we test our rules with it and include changes from the upstream configuration. But depending on your preferences, either of those listed configurations is a good starting point for writing your own configuration.
Do not deploy those configurations to your production environment without prior testing.
It is expected that some tools you use will be the source of huge log volume and should be tuned in the configuration depending your environment.
18.104.22.168.3. Sysmon Installation¶
Sysmon is part of Microsoft Sysinternals and therefore has to be installed as a third party tool. The preferred way to distribute Sysmon and its configuration is using your organization's device management. If you do not have access to one, you can use ASGARD's playbook feature to distribute Sysmon and update its configuration. Documentation which describes the playbook creation and that offers maintenance scripts can be found in our asgard-playpooks repository.
This chapter explains how to configure LogWatcher using Sigma rules.
Service Control ->
Services the Overview of all Assets with an installed service controller is shown. Clicking on the entry opens a drop-down menu with details and additional information.
22.214.171.124.2. Enable Service for an Asset¶
To enable the LogWatcher service for an asset, navigate to
Service Control >
Services, select the asset's checkbox and choose
Change Configuration. Then choose the desired service configuration by clicking
If you have not configured a service yet, you need to do so beforehand.
126.96.36.199.3. Creating a Service Configuration¶
A service configuration is used to group assets of similar type and assign them a set of rules (in form of rulesets).
Service Control >
Service Configurations >
Create Service Configuration, enter a name, choose the LogWatcher service type and add the rulesets that should apply for this service configuration (i.e. group of assets).
If you have not configured a ruleset yet, you need to do so beforehand.
188.8.131.52.4. Creating a Ruleset¶
Rulesets are used to group rules to manageable units. As an asset can only have one service configuration, rulesets are used to determine which rules are used in which service configuration. To create a ruleset go to
Service Control >
Sigma: Rulesets >
After creating a ruleset, go to
Service Control >
Sigma: Rules to choose the rules that should be added to this ruleset by selecting the checkboxes and then
Add to Rulesets. A rule can be assigned to multiple rulesets.
You need to commit and push your changes after editing a ruleset. ASGARD has to restart the service controller to read new configurations. In order to prevent multiple restarts in the case of a user performing several configuration changes in succession, the user has to initiate the reloading of the new configuration by going to
Service Control >
Sigma: Rulesets and performing the Commit and Push action (gear wheels). The need for committing and pushing is indicated in the Uncommitted Changes column.
184.108.40.206.5. Choosing which Rules to activate¶
It is not advised to enable all available rules on an asset. We suggest to start with all "critical" rules. Only then advancing to the "high" rules. "Medium" rules should not be enabled in bulk or "low"/"informational" at all . Single medium rules, which increase an organisation's detection coverage and do not trigger a bigger number of false positives can be added to the active configuration, but should be tested rule by rule.
In order to easily add rules to a ruleset you can use the column filters to select the desired rules and add the bulk to a ruleset. As an example you can add all rules of level "critical" to a ruleset:
Another great way to pivot the sigma rule database is the usage of MITRE ATT&CK® IDs.
Or you can just search the title or description field of the rules (the description column is not shown by default and has to be added using the
4.8. Evidence Collection¶
4.8.1. Collected Evidences¶
ASGARD provides two forms of collected evidence:
- Playbook output (file or memory collection, command output)
- Sample quarantine (sent by THOR via Bifrost protocol during the scan)
All collected evidence can be downloaded in the "Collected Evidence" section.
4.8.2. Bifrost Quarantine¶
If Bifrost is used with your THOR scans, all collected samples show up here. You will need the "ResponseControl" permission in order to view or download the samples. See section
User Roles within the
User Management section for details.
ASGARD requires an Issuer-License in order to scan systems. The Issuer-License contains the number of asset-, server- and workstation systems that can be scanned with ASGARD Management Center.
ASGARD will automatically issue a valid single-license for a particular system during its initial THOR scan.
The screenshot below shows the licensing section of an ASGARD.
In addition, ASGARD can create single-licenses that can be used for agentless scanning. In this case the license is generated and downloaded through the Web frontend.
The following systems require a workstation license in order to be scanned:
- Windows 7 / 8 / 10
- Mac OS
The following systems require a server license in order to be scanned:
- All Microsoft Windows server systems
- All Linux systems
4.10.1. Provide an THOR Incident Response License (optional)¶
In case you have an THOR Incident Response license and want to use it with ASGARD, just upload it through the web based UI. This will remove all endpoint count restrictions from ASGARD. You can scan as many endpoints as you like – regardless of the type (workstation / server).
4.11.1. ASGARD Updates¶
ASGARD will search for ASGARD updates on a daily basis. Available updates will automatically be shown in the section "Updates".
As soon as an ASGARD update is available, a button
Install Update appears. Clicking this button will start the update process. The ASGARD service will be restarted and the user will be forced to re-login.
4.11.2. Updates of THOR and THOR Signatures¶
By default, ASGARD will search for signature updates and THOR updates on an hourly basis. These updates will be set to active automatically. Therefore, a triggered scan will always employ the current THOR version and current signature version. You may disable or modify the automatic THOR and Signature updates by deleting or modifying the entries in this section. In the screenshot below no automatically updates are configured.
It is possible to intentionally scan with an old scanner version by clicking on the pencil icon and selecting the respective version from the drop-down menu.
Please be aware, that this is a global setting and will affect all scans!
4.11.3. Agent Updates¶
If an asset or an gent can be update, there will be a notice shown in the "Update > Agents" tab.
4.12. User Management¶
Access user management via
Users. This section allows administrators to add or edit user accounts.
Editing a user account does not require a password although the fields are shown in the dialogue.
Access the user roles in
By default, ASGARD ships with the following pre-configured user roles. The pre-configured roles can be modified or deleted. The ASGARD role model is fully configurable.
Note that all users except users with the right
Readonly have the right to run scans on endpoints.
The following section describes these predefined rights and restrictions that each role can have.
|Allows scan templates management|
|Run playbooks, including playbooks for evidence collection, to kill processes or isolate an endpoint|
|Connect to endsystems via remote console|
|Review the recordings of all remote console sessions|
|Creat and start scans with predefined arguments or scan templates that are not restricted|
|Cannot view inactive assets in asset management.|
|Cannot start scans or task (playbooks)|
|Can't change anything, can't run scans or response tasks. Used to generate read-only API keys|
4.12.4. LDAP Configuration¶
In order to configure LDAP, navigate to
LDAP. In the left column you can test and configure the LDAP connection itself.
In the right column, the mapping of LDAP groups to ASGARD groups (and its associated permissions) is defined.
First check if your LDAP server is reachable by ASGARD by clicking "Test Connection".
Then check the bind user you want to use for ASGARD. Read permissions on the bind user are sufficient.
To find out the distinguished name you can use an LDAP browser or query using the Powershell AD module command
Next configure the LDAP filters used to identify the groups and users and their preferred attributes in your LDAP structure. A default for LDAP and AD in a flat structure is given in the "Use recommended filters" drop-down menu, but you can adapt it to your liking. The test button shows you if a login with that user would be successful and which groups ASGARD identified and could be used for a mapping to ASGARD groups.
If you need to adapt the recommended configuration or want to customize it, we recommend an LDAP browser such as ADExplorer from Sysinternals
to browse your LDAP structure. As an example you could use your organisation's e-mail address as a user login name if you change the "User Filter"
You need to save the configuration by clicking
Update LDAP Config.
Using the test buttons only uses the data in the forms, but does not save it, so that you can use it for testing purposes anytime, without changing your working configuration.
After the LDAP configuration is set up, you need to provide role mapping from LDAP groups to ASGARD groups.
This is done in the right column by using the
Add LDAP Role feature.
All local users, except the built-in admin user, get disabled when LDAP is configured.
Enabling LDAP authentication disables personal API keys, password changes and 2FA for all user accounts except admin. (LDAP users cannot use said features).
4.13. Other Settings¶
4.13.1. Syslog Forwarding¶
Syslog forwarding can be configured in
RSYSLOG. To add a forwarding for local log source click
Add Rsyslog Forwarding.
The following log sources can be forwarded individually:
|ASGARD Log||Everything related to the ASGARD service, processes, task and scan jobs|
|ASGARD Audit Log||Detailed audit log of all user activity within the system|
|Agent Log||All ASGARD agent activities|
|THOR Log||THOR scan results (available if scan config has
4.13.2. TLS Certificate Installation¶
Instead of using the pre-installed self-signed TLS Certificate, users can upload their own TLS Certificate for ASGARD.
In order to achieve the best possible compatibility with the most common browsers, we recommend using the system’s FQDN in both fields
Common Name AND
Please note that the generating a CSR on the command line is not supported.
This CSR can be used to generate a TLS Certificate. Subsequently, this TLS Certificate can be uploaded in the
4.13.3. Manage Services¶
The individual ASGARD services can be managed in
Services. The services can be stopped or restarted with the respective buttons in the
4.13.4. NTP Configuration¶
The current NTP configuration can be found in the NTP sub-section.
A Source Pool or Source Server can be removed by clicking the
X button. To create a new Source Pool or Source Server, click
Add NTP Source in the upper right corner.
4.13.5. Settings for Bifrost¶
Bifrost allows you to automatically upload suspicious files to your ASGARD during a THOR scan. If an Analysis Cockpit is connected, these files get automatically forwarded to the Analysis Cockpit in order to drop them into a connected Sandbox system. However, the collected files will stay on ASGARD for the amount of time specified in
Retention time (0 days represent an indefinite amount of time).
The collected files can be downloaded in the
Evidence Collection section. All files are zip archived and password protected with the password
In order to automatically collect suspicious files, you have to create a scan with Bifrost enabled. Check the
Send Suspicious Files to ASGARD option to send samples to the system set as
bifrost2Server. Use the placeholder
%asgard-host% to use the hostname of you ASGARD instance as the Bifrost server.
This will collect all files with a score of 60 or higher and make them available for download in ASGARDs
Collected Files section.
For Details on how to automatically forward to a sandbox system please refer to the Analysis Cockpit manual.
4.13.8. Change Proxy Settings¶
In this dialogue, you can add or modify ASGARDs proxy configuration. Please note, you need to restart the ASGARD service (Tab Services) afterwards.
The Advanced tab lets you specify additional global settings. The session timeout for web-based UI can be configured. Default is 24 hours. If
Show Advanced Tasks is set, ASGARD will show system maintenance jobs (e.g. update ASGARD Agent on endpoints) within the response control section.
Inactive assets can be hidden in the Asset Management Section by setting a suitable threshold for
Hide inactive Assets.
Finally, the download for THOR packages can be protected with a token. If unprotected, anybody can request a THOR package with a valid license for a particular host just by sending a https request with the hostname included (for Details see chapter 4.10 Generate Download Links). This may lead to unwanted exhaustion of the ASGARD license pool.
4.14. User Settings¶
4.14.1. Changing your password¶
To change your password, navigate to the
User Settings section.
4.14.2. API Key¶
This section also allows you to set and modify an API key.
Note that currently an API key always has the access rights of the user context in which it has been generated. If you want to create a restricted API key, add a new restricted user and generate an API key in the new user’s context.
4.15. Uninstall ASGARD Agents¶
The following listings contain commands to uninstall ASGARD Agents on endpoints.
The commands contain names used by the default installer packages. In cases in which you've generated custom installer packages with a custom service and binary name, adjust the commands accordingly.
4.15.1. Uninstall ASGARD Agents on Windows¶
sc stop asgard2-agent sc delete asgard2-agent sc stop asgard2-agent_sc sc delete asgard2-agent_sc del /F /Q C:\Windows\System32\asgard2-agent
Line 3 and 4 are only necessary if the new service controller (on ASGARD 2.11+) has been installed.
4.15.2. Uninstall ASGARD Agents on Linux¶
yum remove 'asgard2-agent*'
apt-get remove 'asgard2-agent*'
/usr/sbin/asgard2-agent-amd64 stop /usr/sbin/asgard2-agent-amd64 uninstall rm -rf /usr/sbin/asgard2-agent-amd64 rm -rf /var/tmp/nextron/asgard2-agent rm -rf /var/lib/nextron/asgard2-agent
4.15.3. Uninstall ASGARD Agents on macOS¶
sudo /var/lib/asgard2-agent/asgard2-agent --uninstall sudo rm -rf /var/lib/asgard2-agent/asgard2-agent