ASGARD Management Center is the central management platform for THOR scans.
It manages distributed THOR scans on thousands of systems, collects and
forwards scan results.
Furthermore, ASGARD can control and execute complex response tasks, if needed.
It features built-in response playbooks for quarantining endpoints, creating
and collecting triage packs, opening remote shells and other actions incident
response specialists will find useful.
Moreover, ASGARD provides an easy to use interface for creation of custom
multi-step response playbooks that can execute any command on endpoints
and collect the respective outputs.
ASGARD Management Center is available as a virtual appliance and also as a
hard appliance. Both are based on Debian Buster and require a setup procedure
in order to generate customized agent installers and cryptographic keys.
This document describes all functions and steps for setup and operation of
the ASGARD Management Center. It will describe how to add systems to be
scanned, as well as performing individual or group scanning with separate parameters.
There are a few things to consider before you start with the installation.
The communication between ASGARD and the ASGARD agent is unidirectional.
The ASGARD agent polls ASGARD in a given time frame and ask for tasks to
execute. There is no active triggering from ASGARD to the ASGARD agent –
we have designed it that way, because we believe that opening a port on
all connected endpoints should and can be avoided.
In environments with up to 500 endpoints, the default polling interval
is 20 seconds. In larger environments the polling interval increases
automatically up to one minute for 2.000 endpoints and 10 minutes for
a configuration with 25.000 endpoints connected to a single ASGARD.
Obviously, large environments are not as responsive as small environments
when it comes to opening remote shells or executing urgent response
tasks. It may take up to 10 minutes for the shell to open or the result
to show up. However, once open, the shell or the response tasks are
very responsive – almost as if it is native on the system.
In order to adapt to specific requirements regarding responsiveness,
the polling behavior can be modified. For details, refer to
Performance Tuning.
The hardware requirements in the next chapter assume that the default polling interval is used.
ASGARD supports using a standard http proxy for the entire Agent to
ASGARD communication. In order to use a proxy, the ASGARD agent must
be repacked after installation. For details, see Creating Custom Agent Installer.
ASGARDs hardware requirements depend on the number of connected
endpoints and also on the intended use. For example, you should
consider using bigger hard disks if you are planning to use Bifrost
or ASGARD's evidence collection feature extensively.
The ASGARD Agent, which is installed on endpoints, uses up to 10MB of RAM.
THOR uses up to 300 MB of RAM additionally when scanning is in progress.
The agent will use up to 50 MB of hard disk. Together with THOR and its
temporary files it uses a maximum of 200 MB in total.
Please note, that some response actions, such as collecting triage packs
or collecting system RAM, require additional disk space.
There are no requirements pertaining to the CPU as scans can be scheduled
in a way that THOR reduces its own process priority and limits its CPU
usage to a configurable percentage.
Supported operating systems are the ones supported by THOR.
Not supported are the operating systems with limited or special THOR support.
ASGARD and other systems which will have to communicate with each other,
need the following ports opened within the network. For a detailed and up
to date list of our update and licensing servers, please visit https://www.nextron-systems.com/hosts/.
The ASGARD systems are configured to retrieve updates from the
following remote systems via HTTPS on port 443/tcp:
Product
Remote Systems
ASGARD packages
update3.nextron-systems.com
THOR updates
update1.nextron-systems.com
THOR updates
update2.nextron-systems.com
All proxy systems should be configured to allow access to these URLs
without TLS/SSL interception. (ASGARD uses client-side SSL certificates
for authentication). It is possible to configure a proxy server, username
and password during the setup process of the ASGARD platform. Only
BASIC authentication is supported (no NTLM authentication support).
ASGARD needs to be able to resolve internal and external IP addresses.
Warning
Please make sure that you install your ASGARD with a domainname
(see Network Configuration). If you do not set the
Domain Name and install the ASGARD package, your clients won't be able
to connect to your ASGARD.
All components you install should have a proper domain name configured
to avoid issues further during the configuration.
We recommend excluding certain folders and binaries from Antivirus scanning.
The exclusions will not only prevent Antivirus engines from removing the
agents and scanner executables but also increase scan speed, since their
real-time engines won't check every file that the scanner has opened for
analysis. This can improve the scan speed by up to 30% and also reduces
the system's CPU load.
We recommend using this list - include all sub folders:
Folder Exclusions including Subfolders
Windows
%SYSTEMROOT%\System32\asgard2-agent\
%SYSTEMROOT%\Temp\asgard2-agent\
Linux
/usr/sbin/asgard2-agent-service
/var/lib/asgard2-agent/
/var/tmp/asgard2-agent/
macOS
/var/lib/asgard2-agent/
/var/tmp/asgard2-agent/
Note
If you have obfuscated the agent name, replace asgard2-agent with your custom agent name.
If you have to create a more specific list that can use wildcards, use
the following list (and replace [random] with the wildcard). If you have
the choice, the broader approach above should be preferred.
Using the more specific list, we've experienced problems with some
AV solutions that even trigger on certain keywords in filenames. They
don't kill the excluded executable but block write access to disk if
certain keywords like bloodhound or mimikatz appear in filenames.
In these cases, the executable exclusions are not enough and you should
use the recommended list of two folders and all sub folders (see above).
McAfee needs Exclusions set in multiple locations. In addition to the
general recommendation, customers with McAfee EDR need to set the following exclusions.
You can do a quick hash check to verify that the download was not corrupted.
We recommend to verify the downloaded ISO's signature as this is the
cryptographically sound method.
The hash and signature file are both part of the ZIP archive you download
from our portal server.
user@host:~$ wgethttps://www.nextron-systems.com/certs/codesign.pem
user@host:~$ openssldgst-sha256-verifycodesign.pem-signaturenextron-universal-installer.iso.signextron-universal-installer.iso
Verified OK
Powershell:
PS C:\Users\user\Desktop\asgard2-installer>Invoke-WebRequest-Urihttps://www.nextron-systems.com/certs/codesign.pem-OutFilecodesign.pemPS C:\Users\user\Desktop\asgard2-installer>"C:\Program Files\OpenSSL-Win64\bin\openssl.exe"dgst-sha256-verifycodesign.pem-signaturenextron-universal-installer.iso.signextron-universal-installer.isoVerified OK
Note
If openssl is not present on your system you can easily install it using winget: wingetinstallopenssl.
Create a new VM with your virtualization software. In this case, we will use VMWare ESX managed through a VMWare VCenter.
The new VM must be configured with a Linux base system and Debian GNU/Linux 10 (64 bits) as target version. It is recommended to upload the ASGARD or MASTER ASGARD ISO to an accessible data store and mount the same to your newly created VM.
Please make sure to select a suitable v-switch or physical interface that
reflects the IP address scheme you are planning to use for the new ASGARD.
Only use one Hard Disk for the installation.
The installation Process is started by clicking on ASGARD Graphical install.
The installer then loads the additional components from the ISO and lets you select location and language.
Warning
Please make sure to select the correct Country, as this will also set your local timezone!
If DHCP is available, network parameters will be configured automatically.
Without DHCP, ASGARD drops into the manual network configuration dialogue.
Without DHCP, ASGARD proceeds with the manual network configuration dialogue.
ASGARD needs to be able to resolve internal and external IP addresses.
Important
Important: Make sure that the combination of hostname and domain
creates an FQDN that can be resolved from the endpoints on which you
intend to install the ASGARD agents. If you've configured a FQDN (hostname +
domain) that cannot be resolved on the clients, no agent will be able
to find and reconnect to the ASGARD server.
This is especially important since your Management Center will create
some certificates during the installation, which will not contain an
IP Address as its Subject Alternative Name (SAN), but only the FQDN!
You will not be able to connect your ASGARD Management Center with
your Analysis Cockpit via IP Address.
ASGARD is intended to be installed with only one disk.
Do not configure your server with multiple disks.
The system won't configure additional disks. Make sure
that your disk has the recommended size. See
Hardware Requirements
for more information.
Finally, write your configuration to the disk by selecting "Yes" and clicking "Continue".
If you are using a proxy to access the internet, enter the proxy details in the next step.
Please note, Internetconnectivityisrequired for the next step – the installation of the ASGARD service.
The base installation is now complete. In the next step we will install the ASGARD service.
For this step Internetconnectivityisrequired.
Use SSH to connect to the appliance using the user nextron and the password you
specified during the installation (if you were using an old ISO to install the base
system, the password is nextron). Now you can run the following command:
sudonextronInstaller-asgard (caution: upper case “i" in the middle). This will install ASGARD.
After installation is complete type sudosystemctlstatusasgard2.
The output should look like the screenshot below with status Active.
Installation is complete, you are ready to log into the web-based GUI.
Login to the ASGARD Web interface with user admin and password admin.
The admin user has limited/restricted access to some sections to ensure the correct
audit of certain actions. In order to access restricted functions which require an
audit please create an user with the corresponding rights under Settings > Users.
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.
Note
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 diagnostics sub menu shows the periodically performed checks
and their status. Clicking the magnifying glass icon shows details
of the performed check. If a check failed it gives a detailed error
message and hints on which steps typically help in resolving the issue.
The traffic light on the left menu always shows if any of those checks
failed by showing a warning or error (i.e. yellow or red light) and
you can click the status to view the diagnostics page as a pop-up.
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 directly downloaded from the ASGARD login
screen through the button DownloadAgentInstallers. A list
of available agents for various operating systems appears.
After the 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.
Note
Full administrative privileges are required for the ASGARD agent
and THOR to operate properly.
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 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.
Since the Agent Installer for Windows is a normal .exe file and not a
.msi file, you need to write your own scripts to deploy the agent via
your management system of choice. We have written an example script in
PowerShell, which should work for most of the tools. Please see the section
Installing ASGARD Agent via Powershell Script and
Deploy ASGARD Agents via SCCM.
Alternatively, if you want to deploy the ASGARD Agent manually, you can
just execute the installer by hand.
You will be able to deploy your agents via most of the common linux tools,
just make sure that the installer is being installed with administrative
priileges.
Starting with macOS Big Sur (v11.0), Apple requires software developers
to notarize applications.
Due to the nature of the asgard2-agent installer, which is generated on
installation time and making it unique for each new installation, it's
currently not possible to notarize the installer.
This document aims to describe possible workarounds intended to be a
reference for IT Administrators or IT packaging teams to bypass Apple
verifications and install the personalized asgard2-agents on their macOS
Big Sur (or newer) workstations.
Warning
Executing any of the workarounds described in this document puts your
system at risk for a short period of time. This document will deactivate
global security mechanisms of the operating system, which are intended to
protect the integrity of the system.
Please always keep in mind to check your systems after performing any of
the described actions to ensure that all security mechanisms are in
place and are re-activated after performing the described actions.
Please follow the below steps to install the ASGARD Agent on macOS.
Open a new terminal session
Deactivate macOS Gatekeeper
sudospctl--master-disable
Close the terminal and open a new terminal session
Since macOS version 13 (Ventura) the ASGARD Agent needs full disk access
to function properly. After you have deployed the ASGARD Agent, you need
to grant the service the required access permissions. Please keep in mind
that administrative privileges on the machine are needed to perform this
change.
To do this, navigate on your Mac to SystemSettings > Privacy&Security > FullDiskAccess:
You need to enable the asgard2-agent-service slider:
Note
There is no workaround to this step, since it is an integral
part of the security design of Apple devices. If you are having trouble
with THOR scans via ASGARD on macOS, please check if the FullDiskAccess permission for the ASGARD agent was granted. Since macOS version
10.14 (Mojave), you need to grant the same permissions if you want to
scan removable volumes.
In the AssetManagement view you can see all the connected ASGARD
agents. New assets will be placed under AssetRequests and need a
manual approval before being able to connect to your ASGARD (for auto
accept see Advanced).
If the DuplicateAssets view is visible, you should try to remediate
the issues in a timely manner, since this might cause unwanted side
effects on the duplicate hosts.
Warning
Assets in the DuplicateAssets view indicate, that one or more
agents are running on multiple endpoints. This might be caused by
cloning a system with an already installed ASGARD 2 Agent. Undesirable
side effects of duplicate assets are alternating hostnames and tasks
that fail immediately.
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.
Available Actions (left to right): Run Scan, Run Task,
Connect To Remote Console, Show Timeline, Enable/Disable Fast Poll Mode
Note
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
The RunScan button might be greyed out in new installations - this is
because ASGARD did not download the THOR packages yet. You can either wait for a
few minutes, or see the chapter Updates of THOR and THOR Signatures,
to trigger a download manually.
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 AddLabels button.
Note
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 RemoveLabels
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.
The import function allows you to add or remove labels on assets based on columns in
the previously generated CSV formatted file.
The import function processes the values in the columns AddLabels... and RemoveLabels...
only. In order to change labels, use the already exported list, add values in these
columns and re-import it by using the ApplyLabelsfromCSV button.
Separate multiple labels with comma. Leading or ending white space characters
will be stripped from the labels.
You can search for Assets in your ASGARD with the ASGARDQuery. This allows
you to write more complex queries to search for assets. Additionally, this
helps you to be more flexible with your scan/response tasks, since you can
just specify a query and don't have to set labels first. A good example of
this might be if you are scanning a specific subnet every week, and a new
agent is being deployed in this subnet. You don't have to think of all the
labels or troubleshoot why scans are not being deployed. One example you
could achieve this with is the following query:
system="linux"andinterfaces="172.16.50.0/24"
This would run the task on all linux systems in the subnet 172.16.50.0/24.
The following operators are available:
Operator
Example
Equals
hostname = "win10-dev"
Equals
cpu_count = 1
Contains
hostname contains "win"
Begins With
hostname begins with "win"
Ends With
hostname ends with "dev"
Numerical Comparison
total_memory >= 4 GB
Numerical Comparison
last_seen < 3 days ago (assets that have not been seen since 3 days)
Numerical Comparison
last_seen > 1 hour ago (assets that have been seen in the last hour)
Numerical Comparison
last_scan_completed < 2022-08-17 (assets that have not been scanned since 2022-08-17)
Numerical Comparison
last_scan_completed < 2022-08-17 15:00:00 (assets that have not been scanned since 2022-08-17 15:00:00)
Numerical Comparison
last_scan_completed is never
Boolean
is_domain_controller is true
Boolean
nextping is true (shows all assets with Fast Poll enabled)
Not
not hostname contains "win"
Not
not hostname ends with "dev"
And
hostname contains "win" and not hostname ends with "dev"
Or
hostname begins with "dev" or hostname ends with "dev"
Nested
hostname ends with "dev" and (hostname contains "win" or hostname contains "lin")
Set / Not Set
labels is set (assets that have at least one label)
Set / Not Set
labels is not set (assets that have no labels)
Regular Expression
hostname matches "^[a-z0-9]{(0,6)}$"
Pattern
Use _ to match any single character and % to match an arbitrary number of characters, including zero characters.
Pattern
arch like "a__64" (matches amd64 and arm64, but not aarch64)
Pattern
arch like "%64" (all 64 bit systems, e.g. amd64, arm64, aarch64 or ppc64)
IP Range
interfaces = "172.28.30.0/24"
You can create simple or complex queries this way. You can group/separate queries with brackets:
You can move an asset from one ASGARD to another via the Maintenance Module of Response
Control. To do this, navigate to AssetManagement and select the assets you want to
migrate. Alternatively you can navigate to ResponseControl and add a new task.
You can now Click the AddTask button to open the Task Menu. Choose the Maintenance
Module and then the MoveassettoanotherASGARD Type. You have to upload an agent
installer from the ASGARD you want to migrate the asset to.
Note
The target OS or Arch of the installer doesn't matter, we will only use the installers
configuration data for the migration.
The task will fail if the migrated asset is unable to communicate with the new ASGARD.
In this case, the asset will remain on the ASGARD which issued the migration task. Only
the asset will be migrated (it shows up as a brand new asset on your new ASGARD), no
scan or response tasks and also no logs will be migrated.
Deleting Assets will remove the assets from the ActiveOnly asset view and will
invalidate the authentication for these assets.
To delete an asset, go to the AssetManagement View and mark the assets you want
to delete. Click the DeleteAssets Button on the top right corner. Confirm that
you want to delete the asset.
To see all the deleted assets, change your view from ActiveOnly to DeletedOnly.
Warning
Deleted assets can no longer communicate with the ASGARD. Please use with caution.
The Scan Control in your ASGARD allows you to run different kind of Scans on one
or multiple assets. Additionally, you can create Scan Templates to use with new
Scans, so the different options don't need to be configured for every new scan.
False-Positive Filters can be set to exclude certain files from scan results,
or even whole directories can be excluded.
Your ASGARD will also take care of THOR scans which stopped (e.g. the asset
rebooted or lost connection to your ASGARD during a scan), so that a scan
will not fail if the asset is temporarily offline.
Scan templates are the most convenient way to make use of THOR's rich set of
scan options. Starting with ASGARD1.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 than 50% of 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 section User Management for details).
By clicking the ImportScanTemplate button you can import a previously exported scan template.
In order to create a scan template, navigate to ScanControl > ScanTemplates
and click the AddScanTemplate button. The AddScanTemplate dialogue appears.
The current THOR scanner version is chosen for you by default but can be changed if needed.
After choosing or changing 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 or quickly search for known flags in the search bar.
By clicking on the star symbols you can also edit your personal favorites.
By checking the "Default" box, you can make this scan template the default template
for every new scan. There can only be one default template at a time and selecting
the box will uncheck a previous default, if set.
Checking the "Restricted" flag will make the template restricted, meaning only a
restricted set of users can use the template for scans. The set of users consists
of all users who do not have the "ForceStandardArgs" restriction set. (By default
this are all users who are not member of the group "Operator Level 1").
After clicking the "Add Template" button on the bottom of the template page, an
overview of all existing scan templates is shown.
If you want to run a Single Scan - instead of a Group Scan - on multiple Assets,
you can do this by navigating to the AssetManagement View and select the
assets you want to scan.
Click the AddScan button in the top right corner and fill in the scan options.
This will create a Single Scan for each asset.
As with the single scans, various parameters can be set. Aside from the already
mentioned parameters, the following parameters can be set:
Parameter
Value
Description
Freely selectable name for the group scan.
Scan Target
Here you can define which assets will be affected by the group scan.
You can either use the Simple target option, which uses labels,
or you can use the Advanced target options, which makes use of
labels or asset queries. Leaving this option empty will scan all assets.
Limit
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 or enter 0 for no limit. If
you are using MASTER ASGARD, this limit is applied on each single selected ASGARD.
Rate
The number of scans per minute that are issued by ASGARD. 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.
Expires
After this time frame, no scan orders will be issued to the connected agents.
Scheduled Start
Select a date for a scheduled start of the scan.
After the group scan has been Saved or SavedandStarted, you will
automatically be forwarded to the list of grouped scans.
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:
Status
Value
Paused
The group scan has not yet started. Either click play or wait
for the scheduled start date (the job will start in a 5 minute window around the scheduled time).
Active
Scan is started, ASGARD will issue scans with the given parameters.
Inactive
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.
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".
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 AddScheduledGroupScan button.
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.
To configure Syslog Forwarding of logs, you can set the --syslog flag
during scans. You have multiple options as to where you can send the logs.
The --syslog value is constructed of the following arguments. Please
keep in mind that the fields need to be in the correct order. Values are
separated with the colon sign :
Pos.
Field
Description
Possible Values
1
Server
The receiving server, %asgard-host% is the ASGARD which issued the Scan for the Agent
FQDN or IP of remote host
2
Port
optional - the listening port on the remote system, default is 514
The syslog listener on the Management Center
is running on port UDP/514.
Examples:
cribl.local:6514
172.16.20.10:514:SYSLOGKV:TCP
rsyslog-forwarder.dom.int:514:JSON:TCP
arcsight.dom.int:514:CEF:UDP
If you choose to use the --syslog flag, please make sure that the
necessary ports are allowed within your network/firewall. If you decide
to forward your logs via ASGARD to a SIEM, please have a look at
Rsyslog Forwarding.
Note
If Syslog Forwarding is selected for a new THOR Scan, the default
target will be set to %asgard-host%, which is your Management
Center. Syslog Forwarding is optional and you do not lose any
functionality if you are not using it (in most cases). If you
want to forward logs in real-time from your Management Center to
a SIEM (for example), you do however have to enable Syslog Forwarding.
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 or system privileges.
In order to replay a remote console session, navigate to ResponseControl,
expand the task that represents your session, select the ConsoleLog tab
and click the play button in the bottom row.
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.
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 ASGARD Agent Log
Create and Collect Aurora Agent Diagnostics Pack (Windows only)
Collect full triage pack (Windows only)
Isolate endpoint (Windows only)
Collect system memory
Collect file / directory
Collect directory
Collect Aurora diagnostics pack
Execute command and collect stdout and stderr
Nextron provides additional playbooks via ASGARD updates.
Warning
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.
If you need custom files for your playbook (scripts, configurations, binaries, etc.)
you can select local files to be uploaded to ASGARD during the creation of the playbook
step (by selecting "Upload New File" in the file drop-down). You can manage these
files at ResponseControl > PlaybookFiles and upload or update files using
the UploadPlaybookFile button.
You can have up to 16 steps in each playbook that are executed sequentially. Every
step 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.
You can change the Proxy Settings on your Assets via the Response Control.
To do this, select the asset(s) and click AddTask in the top right corner.
Next, set the Module to Maintenance and the Maintenance Type to
Configuretheasset'sproxy. You can now set your proxy. Multiple proxies
can be set, though only one FQDN/IP-Address per field can be set.
Service Control is ASGARD's way of deploying real-time services on endpoints.
Currently there exist the Aurora and the LogWatcher service. To use any of those
two, the service controller has to be installed on an asset.
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.
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 AssetManagement >
Assets > RunTask (play button action) or analogous as a (scheduled) group task
under ResponseControl > (Scheduled)GroupTasks > Add(Scheduled)GroupTask.
LogWatcher, as well as Aurora, are using Sigma in order to define their detections.
The Sigma rule management is shared between the two services. But each service has
its own configuration that defines which rules are actually used on the assets.
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.
Sigma is for log files what Snort is for network traffic and
YARA is for files.
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. There exist default
rulesets for high and critical Sigma rules. If you want to create a
custom ruleset go to ServiceControl > Sigma > Rulesets > CreateRuleset.
If you have chosen that new Sigma rules should be added automatically
they are added now. If you didn't you now need to add the desired rules
manually by going to ServiceControl > Sigma > Rules. Choose
the rules that should be added to this ruleset by selecting the checkboxes
and then AddtoRuleset. 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 ServiceControl >
Sigma > Rulesets and performing the Compile ruleset action
(gear wheels). The need for compiling is indicated in the Uncompiled Changes column.
It is not advised to enable all available rules on an asset. We suggest
to start with all "critical" and then advance to all "high" rules. We
already provide a default ruleset for those two levels for you to use.
"Medium" rules should not be enabled in bulk or "low"/"informational"
at all . Single medium rules, which increase an organization'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:
Or you can just search the title or description field of the rules. You can also search
the rule itself using the "Rule" column. (the "Rule" column is not shown by default and
has to be added using the gear wheel button).
Not every environment is the same. It is expected that some rules will trigger false
positive matches in your environment. You have
multiple options to tackle that issue.
If it is a general false positive, probably not only occurring in your environment,
consider reporting it at as a Github issue
or e-mail to us (rules@nextron-systems.com). We
will take care of the tuning for you and your peers.
If the false positive is specific to your environment you can tune single Sigma rules
at ServiceControl > Sigma > Rules, filter for the rule in question and
choose the "Edit false positive filters of this rule" action. Here you can do simple
rule tunings on your own. By clicking the AddFalsePositiveFilter button you can
add single lines that filter the event for false positives (i.e. they are OR-connected
meaning: "Do not match the event if any of those lines matches). They are applied on top
of the rule logic and persist automatic rule updates.
Example of the false positive tuning of a Sigma rule
To see the resulting rule you can click the "Show Preview" button or look at the
"Compiled Rule" row in the rule's drop down menu.
If you want to review the tuned rules: To filter for all rules containing a custom
false positive tuning, you have to add the "Filters" column to your view (gear wheels
icon) and show all non-empty rows by using the NOT- column filter.
If the rule is adding too much noise and tuning is not sensible, you can remove the
rule from the ruleset for a subset of your machines (maybe you need to define and use
a separate ruleset for that use-case) or you can disable the rule altogether. This
is done using the Disablethisrule action of the rule. Disabling the rule affects the rule in all rulesets.
After tuning a rule, the rulesets using that rule have to be re-compiled at ServiceControl > Sigma > Rulesets.
Custom rules can be added using the sigma format complying with the
specification. You can
upload single files or a ZIP compressed archive. This can be done at
ServiceControl > Sigma > Rules > UploadRules.
If new rules or rule updates are provides by the Aurora signatures, the updates
have to be applied by the user manually in order to be affecting Aurora agents
managed by ASGARD. An indicator is shown in the WebUI and the rules changes can
be reviewed and applied at ServiceControl > Sigma > RuleUpdates.
Clicking on the Update button in the "Update Available" column opens a diff
view in which the changes are shown and where the user can apply or discard the
changes. If you do not need to review each single change, you can apply all
changes using the UpdateAllRules button.
Analogous the updates of response actions can be viewed and applied at
ServiceControl > Sigma > ResponseUpdates.
As a fail safe and for administration purposes, responses are generally
only simulated if not explicitly set to active.
This has to be done on different levels:
Service configuration level
Ruleset configuration level (on updates)
Ruleset rule level
If on one level a rule is simulated, it will not execute the response
actions but only generate a log line that describes the action that
would have been performed. You can see an overview of the state of all
responses in the ServiceControl > Aurora > Configurations menu.
indicates whether responses are activated on configuration level. Edit the configuration to change it.
indicates how many rules are only simulated in that ruleset (or in sum).
indicates how many rules have active responses in that ruleset (or in sum)
To change the status of a response in the ruleset click the ruleset link.
You can view all simulated or all active responses. Use the checkbox and
the button in the upper right to switch the response status of the rules
between active and simulated.
In addition the default response mode of a ruleset is important for the
behavior of response updates. It can be seen at ServiceControl >
Sigma > Rulesets in the "Default Response Mode" column.
If "Simulation" is selected, response actions of new and updated rules
will be put in simulation mode. If "Active" is selected, new rules will
automatically be put in active mode and updated rules will not change
their current response mode.
Under ServiceControl > Aurora > AssetView(Deployed) the overview
of all assets with installed Aurora is shown. Clicking on the entry opens a
drop-down menu with details and additional information.
Analogous you can see an overview of all assets without Aurora installed under
ServiceControl > Aurora > AssetView(NotDeployed) and install
Aurora using the DeployAurora button.
To change the Aurora configuration of an asset, navigate to ServiceControl
> Aurora > AssetView(Deployed), select the asset's checkbox and choose
> ChangeAuroraConfiguration. Then choose the desired service configuration
> by clicking AssignandRestart.
If you want to enable or disable the Aurora service on an asset, select it
with the checkbox and use the Enable or Disable button or select
the play or stop action icon on single assets.
Go to ServiceControl > Aurora > Configurations > AddConfiguration,
enter a name and add the rulesets that should apply for this service configuration.
No rulesets is a viable option, if you only want to use the non-sigma matching modules.
You don't need to edit any other option as sane defaults are given.
If Aurora uses too much CPU cycles, the most common reason is a heavy event
producer on the system (e.g. anti virus or communication software). In order
to analyze the issue and define process exclusions, go to ServiceControl >
Aurora > ProcessExcludes
An overview over the top event producing processes is given on the bottom
of the section. Another possibility is to
collect diagnostic packs of systems
in question and look in the status.txt at the event statistics by process.
If needed, false positives can be globally filtered on all Aurora agents
at ServiceControl > Aurora > FalsePositiveFilters. It is
recommended to filter false positives at ServiceControl > Sigma >
Rules and filter the false positives on a rule level using the "edit false
positive" action (funnel icon). For more details see
False Positive Tuning of Sigma Rules. If this is
not possible, because you need a quick fix and multiple rules are affected,
the global false positive filter can help.
If you want to enable the blocking capabilities of Aurora, we suggest
to enable our included responses:
See the overview at ServiceControl > Aurora > Configurations.
The EffectiveRulesandResponse row shows how many responses are active.
By default no responses are active. See How to activate Responses
on how to activate responses.
Do not directly activate the responses in production environments. Monitor
your environment for at least a month with simulated responses to verify
that no false positive matches occur.
In larger environments use different configurations and rulesets for different
environments. As an example you can test changes to the configuration in a
test environment, before adapting the changes for the production environment.
You can test the response functionality by entering the command
More tests are available from the
Function Tests section of the Aurora manual.
Those tests only generate detection events but no responses. If your ASGARD Management
Center is connected to an Analysis Cockpit, you can see the detection events at Events >
AuroraEvents or in the Windows EventLog of the asset.
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. The LogWatcher service is no
longer shown by default on newly installed ASGARDs. To enable it go to Settings >
Advanced and enable the ShowLogWatcher checkbox.
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.
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.
There are some best practice 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
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.
Warning
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.
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-playbooks repository.
Under ServiceControl > LogWatcher > AssetView(Deployed)
the overview of all assets with an installed LogWatcher is shown.
Clicking on the entry opens a drop-down menu with details and additional information.
To enable the LogWatcher service for an asset, navigate to ServiceControl >
LogWatcher > AssetView, select the asset's checkbox and choose
AssignConfiguration. Then choose the desired service configuration
by clicking Assign.
Creating a Custom Logwatcher Service Configuration
A service configuration is used to group assets of similar type and
assign them a set of rules (in form of rulesets).
Go to ServiceControl > LogWatcher > Configurations >
AddConfiguration, enter a name and add the rulesets that
should apply for this service configuration (i.e. group of assets).
The menu IOCManagement gives you the opportunity to easily integrate custom signatures into your scans.
In order to create your own custom IOC Group, navigate to IOCManagement > IOCs
and click AddIOCGroup in the upper right corner. Select a name and optionally a description for your IOC Group.
To add IOCs to this group, use the ShowandeditIOCsinthisIOCgroup
action. A side pane opens where you can click the ImportIOCs button
to import your own signatures in any of THOR's IOC formats as files (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 AddIOC(s) button to add some IOCs
interactively. Select the type, score and description, enter some values
and click the AddIOC button.
You can add those IOC Groups to IOC Rulesets which can be created in
the IOCManagement > IOCRulesets tab by clicking the AddRuleset
button in the upper right corner. Select name and description and click the
AddRuleset button.
After that, click on an entry in the table to expand it. There you
get information about all IOC Groups which have been added to this
ruleset. Additionally you can add or remove selected IOC Groups in
IOCManagement:IOCs by clicking one of the three buttons shown below.
Those rulesets can be selected in the "IOC Rulesets" 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.
The THOR scan would be performed with the default settings and the
custom ruleset, the default signatures would not be applied.
In order to use MISP events and their IOCs for scanning, you
need to link your ASGARD with a MISP first. Please see
Link MISP for reference.
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 IOCManagement > MISP > MISPEvents, select
the IOCs and add them to the desired ruleset by using the button in
the upper right corner.
There is no default ruleset for MISP. You must create at least one
ruleset (see tab "MISP Rulesets") before you can add MISP rules.
To create a new ruleset, click AddMISPRuleset in the
IOCManagement > MISP > MISPRulesets 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. Enable AutoCompile in order
to automatically compile new MISP events into the ruleset, when they arrive.
Since not all the information and attributes in a MISP event are
relevant to ASGARD and the THOR scanner, we provide a list of
attributes which will be used by ASGARD:
hostname
ip-dst
domain
domain-ip>hostname
domain-ip>ip-dst
domain-ip>domain
filename
filepath
file>filename
file>filepath
file>md5
file>sha1
file>sha256
md5
sha1
sha256
yara
yara>yara
sigma
Warning
Only attributes with the flag IDS set to true will be used
by ASGARD. Please make sure that the flag is set if you are
intending to use certain events/attributes.
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 Roles and
Rights for details.
The Downloads section lets you create and download a full
THOR package including scanner, custom IOCs and MISP rulesets
along with a valid license for a specific host. This package can
then be used for systems that cannot be equipped with an ASGARD
agent for some reason. For example, this can be used on air gapped
networks. Copy the package to a flash drive or CD ROM and use it
where needed.
You can choose to disable the download token altogether using
DisableDownloadToken. If disabled, anyone with network
access can download and issue licenses, which may lead to
unwanted exhaustion of the ASGARD license pool. You can reset
the download token by disabling and then re-enabling it using NewDownloadToken.
Download THOR package and license workstation named 'WIN-CLI-DE-1234'
While selecting different options in the form, the download link changes.
After you have generated a download token and have selected the
correct scanner, operating system and target hostname (not FQDN),
you can copy the download link and use it to retrieve a full
scanner package including a license file for that host. These download
links can be sent to administrators or team members that don't have
access to ASGARD management center. Remember that the recipients of
that link still need to be able to reach ASGARD's web server port
(443/tcp). The token can be used to download THOR or a THOR license
without an ASGARD account. Attention: If you disable the token,
anybody can download THOR from this ASGARD or can generate licenses.
Note
The scanner package will not contain a license file if you don't
set a hostname in the TargetHostname field. If you have an
Incident Response license, you must provide it separately.
You can generate download links without an included license by
leaving the hostname field empty. A valid license (e.g. "Incident Response")
must be placed in the program folder after the download and extraction.
By including the hostname in the form, a license will be generated
and included in the download package You can copy the final download
link and send it to anyone, who can use this link to download a
package and run scans on a host with that name.
You or the recipient can change the name in that URL to make it
usable on other systems.
Note that you may have to adjust the type field to get the correct
license type (client for workstations, server for servers) and
the THOR version (win, linux, osx) to generate a correct URL.
By default, the generated download link is protected with a
token that makes it impossible to download a package or
generate a license without knowing that token. This token
is specific to every ASGARD instance.
You can use that URL in Bash or PowerShell scripts to automate
scans on systems without an installed ASGARD agent.
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 as well as the Aurora or LogWatcher service licenses.
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 agent-less 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 / 11
Mac OS
The following systems require a server license in order to be scanned:
All Microsoft Windows server systems
All Linux systems
The licenses are hostname based except for asset licenses. Asset
licenses are issued for each accepted asset as soon as a response
action is performed (playbook or remote console access).
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 Upgradefrom...to...
appears. Clicking this button will start the update process. The
ASGARD service will be restarted and the user will be forced to
re-login. Generally update MASTER ASGARD before the connected ASGARDs.
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.
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!
You can trigger a Manual Check and download new THOR packages by clicking
ManuallyCheckforUpdates. This can also be used in new ASGARD
installations, as sometimes it takes a while until ASGARD does this automatically.
Editing a user account does not require a password although
the fields are shown in the dialogue. An initial password
has to be provided for user creation, though.
Access the user roles in Settings > Roles.
You can download a list of all users in CSV format.
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.
In order to configure LDAP, navigate to Settings > 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 Get-ADUser<username>.
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 organization's e-mail address as a user login name if you change the "User Filter"
to (&(objectClass=user)(objectCategory=user)(userPrincipalName=%s))
Note
You need to save the configuration by clicking UpdateLDAPConfig.
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 AddLDAPRole feature.
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
Thor Log (Realtime)
The THOR (Realtime) logs are the same logs as THOR logs,
except that they are collected via udp syslog instead of
https. To forward THOR logs in realtime, you have to
configure your scans to forward syslog to ASGARD, see
Syslog Forwarding). Make
sure the necessary firewall rules are in place to allow
the asset to communicate with the ASGARD.
In order to achieve the best possible compatibility with the
most common browsers, we recommend using the system's FQDN
in both fields CommonName AND Hostnames.
Please note that generating a CSR on the command line is not supported.
The generated CSR can be used to generate a TLS Certificate.
Subsequently, this TLS Certificate can be uploaded in the Settings > TLS section.
The individual ASGARD services can be managed in Settings > Services.
The services can be stopped or restarted with the respective buttons in the Actions column.
A Source Pool or Source Server can be removed by clicking the delete action.
To create a new Source Pool or Source Server, click AddNTPSource in
the upper right corner.
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 Retentiontime (0 days represent an indefinite amount of time).
The collected files can be downloaded in the EvidenceCollection
section. All files are zip archived and password protected with the password infected.
In order to automatically collect suspicious files, you have to
create a scan with Bifrost enabled. Check the SendSuspiciousFilestoASGARD
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.
In order to connect to an Analysis Cockpit, enter the
respective hostname of the Analysis Cockpit (use the same
FQDN used during installation of the Analysis Cockpit) in
the field FQDN, enter the one-time code, choose the
type and click UpdateAnalysisCockpit.
ASGARD must be able to connect to the Analysis Cockpit
on port 443/TCP for a successful integration. Once connected,
the Cockpit will show up in ASGARDs SystemStatus > Overview
section together with the other connectivity tests.
Please wait up to five minutes for the status to
change on ASGARD's system status page. It will change from Notlinked to Online.
In order to connect to a MISP with your ASGARD Management Center,
navigate to Settings > MISP. Insert the MISP's address,
along with the API Key and click TestandLinkMISP.
The MISP connectivity status is shown in the Overview section.
Please allow five minutes for the connection status to indicate the
correct status, and also MISP rules to be downloaded and shown in
IOCManagement > MISP > MISPEvents.
This will also overwrite any changes made to the file
/etc/apt/apt.conf.d/proxy on your system. If you
changed the file before installation of your ASGARD
services (Changing Proxy Configuration),
you can safely go ahead and change your proxy settings.
In order to control your ASGARD with a MASTER ASGARD,
you must generate a One-Time Code and use it in the "Add ASGARD"
dialogue within the MASTER ASGARD frontend.
The Advanced tab lets you specify additional global settings.
The session timeout for web-based UI can be configured. Default
is one hour. If ShowAdvancedTasks 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 HideinactiveAssets.
We are currently using the Time-basedOne-timePassword(TOTP)
algorithm for two factor authentication. We recommend
one of the following mobile apps for 2FA:
To enable Two Factor Authentication, navigate to UserSettings >
TwoFactorAuthentication. If 2FA is not enabled, you
will see the option to UseTwoFactorAuthentication.
After clicking the button, you will be presented with a QR
code for your authenticator app of your choice.
Alternatively, you can use the secret key. You will need
to verify the 6-digit token and click ValidateTwoFactorAuthentication
to enable 2FA.
Note
You will be logged out of your current session if the validation was successful.
To generate an API Key, navigate to UserSettings > APIKey.
This page allows you to set an API key. If an API key was previously set,
a new key will be generated. You will only be able to see your new API key
once after it has been generated.
Note
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.
Warning
The API key has the same rights as your user. Do not use your
API key as token for license generation and license / THOR download.
Instead, use the download token from the Downloads menu
(Generate Download Links).
The following listings contain commands to uninstall ASGARD Agents on endpoints.
Note
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.
You need administrative privileges to remove the ASGARD Agent from Windows.
Open a command prompt with administrative privileges and run the following commands:
The command contains 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.
If you want to uninstall the ASGARD Service Controller and Agent,
see section Uninstall ASGARD Agents.
If you only want to uninstall the ASGARD Service Controller execute:
MASTER ASGARD is a single central management console that can control
all of your ASGARD systems. It is meant to centrally manage controlled
scans on all your ASGARD systems. MASTER ASGARD also provides one central
point of management for your Response Playbooks, Evidence Collection
and IOC Management. A special license for this is needed.
To install a Master ASGARD, you have to choose the command line argument
-masterasgard after the installation from our ISO. This has to be
a new system, you cannot install a MASTER ASGARD on an existing ASGARD
Management Center.
After the MASTER ASGARD and later its license have been installed, many
functions offer additional options. From that moment onwards, your
MASTER ASGARD can use all endpoints connected to your linked ASGARD systems,
just like a normal ASGARD.
Once you connect your ASGARD Management Centers to your MASTER ASGARD,
the licensing sections on connected ASGARD Management Centers become inactive.
The local ASGARD license will be replaced with the MASTER ASGARD license.
Every ASGARD can issue scanning licenses to assets as long as the
total number of scanned servers and workstations does not exceed the
number of systems in the MASTER license.
In MASTER ASGARD go to ConnectedASGARDs, click the AddASGARD
button in the upper right corner, and use the hostname and one-time token to
connect that ASGARD system. You can use a description to provide more
information on that ASGARD server, e.g. DMZ1 or RegionEMEA-HQ1.
You don't have to provide a port in the hostname field. Don't use a
URL like https://, just the FQDN. Remember that MASTER ASGARD
must be able to reach ASGARD v2 systems on port 5443/tcp and ASGARD
v1 systems on port 9443/tcp. Also make sure that the MASTER ASGARD
system is able to resolve the FQDN of the ASGARD system.
Scan Control in MASTER ASGARD looks the same as in an ASGARD server.
The only difference is that you can select an ASGARD Server or "All ASGARDs" to run the scans on.
On MASTER ASGARD you can manage IOCs exactly like on ASGARD. The only
limitation is that IOCs in MASTER ASGARD and ASGARD are isolated. That
means if you want to use the IOCs from MASTER ASGARD, you need to initiate
the scan from MASTER ASGARD and if you want to use the IOCs from ASGARD,
you need to initiate the scan from ASGARD. In general we suggest to
manage IOCs in MASTER ASGARD for maximum flexibility.
Service Control lists the asset with an installed service controller.
An asset is either managed by MASTER ASGARD or its connected ASGARD, not
by both. If an asset is managed by MASTER ASGARD it can still be viewed
by the connected ASGARD (and vice versa). If MASTER ASGARD or ASGARD
edits a configuration of an asset it will take over the "leadership"
over this asset, no matter by which it was managed beforehand.
Example: Service Controller listed in ASGARD but managed by MASTER ASGARD
The Downloads section of MASTER ASGARD allows to generate and
download Agent Installers on all your connected ASGARDs. This
allows for a central management of the Installers.
Example: Download Section in ASGARD but managed by MASTER ASGARD
It is possible to set a certain THOR and Signatures version for each
connected ASGARD. However, if automatic updates are configured, this
setting has only effect until a new version gets downloaded.
Customers use this feature in cases where they want to test a certain
THOR version before using it in production. In this use case the ASGARD
system that runs the test scans is set to automatic updates, while the
ASGARD systems in production use versions that administrators set manually
after successful test runs.
MASTER ASGARD offers no central user and role management for all connected
ASGARD servers. Since MASTER ASGARD and ASGARD allow to use LDAP for
authentication, we believe that complex and centralized user management
should be based on LDAP.
It is not possible to link a MASTER ASGARD with an Analysis Cockpit and
transmit all scan logs via MASTER ASGARD to a single Analysis Cockpit
instance. Each ASGARD has to deliver its logs separately to a connected
Analysis Cockpit.
ASGARD is rotating logs automatically at a set time interval. It is
important to keep in mind how long logs will be stored on the system
before they get purged. All logs will be rotated and zipped into one
file monthly, for up to 14 months.
To get a better understanding of how the log rotation is handled,
you can inspect /etc/logrotate.d/asgard.
ASGARD will store all logs under /var/lib/nextron/asgard2/log/.
This does not include the Scan Logs, as those are handled separately.
If you require a longer retention period, please copy the oldest log
packages to another directory or to a dedicated log server. Do not
modify the built-in rotation settings as this might interfere with ASGARD updates!
Log
Name
Audit
asgard-audit.log
ASGARD Management Center
asgard.log
Agent Agent and Service Controller
agent.log
THOR via Syslog
scan.log
THOR via Syslog (Scan Start, Licensing, Completion only)
subscan.log
If you want to forward those logs automatically to a dedicated server,
you can set up Rsyslog Forwarding. Forwarded
logs will still reside on ASGARD.
The following files are safe to delete. They are not needed for ASGARD to operate.
/var/lib/nextron/asgard2/log/*.gz
They are only kept on the system if needed for further processing.
E.g. saving/sending the log files to another system. If you do not
need or plan to use those, they can be deleted. If you are unsure
make a copy to another system before deleting them.
/var/lib/nextron/asgard2/downloads/* (except current day)
The files in this folder are only generated for temporary downloading
files from the UI and are not needed after the download has finished.
The directory has a sub structure of year/month/day. It is save to
delete any files older than the current day.
If you use Bifrost, the collected files are not deleted by default.
If dated files are no longer needed, you can define a retention
period at Settings > Bifrost.
The listed files are the results of THOR scans (scan-results), Tasks
except Scans (generic-results) and the sessions of remote consoles (remote-console).
They are not needed for ASGARD to function, but the data is viewed and
available for download in ASGARD. This means deleting these files will
not break ASGARD, but you lose the information provided by the files.
If you need the disk space and cannot increase the disk, we suggest to
delete these files older than a given date, that you no longer need.
This can be done with a find-remove combination using the command line:
Where <directory> is one of scan-results/*.gz, generic-results/* or remote-console/protocol/*
and <days> the number of days you want to keep. Files and folders older than <days> days will be deleted.
The ASGARD agent polls the ASGARD server frequently for new tasks to execute.
The default polling interval depends on the number of connected endpoints. In
larger environments the polling interval increases dynamically up to 10 minutes
for a configuration with 25.000 endpoints connected to a single ASGARD.
Additionally, ASGARD is configured to serve a maximum of 100 concurrent asset
connections and 25 concurrent asset streams. Asset connections are short polls
from the agent such as answering the question "do you have a new task for me?".
Asset streams are intense polls such as downloading THOR to the agent or
uploading scan results back to ASGARD.
Requests that exceed the limits will receive an answer from ASGARD to repeat the
request after N seconds, where N is calculated based on the current load.
This factory preset behavior insures your ASGARD stays stable and responsive even if your
ASGARD's system resources are limited. Furthermore, you most likely can't overload your
network or firewalls with high numbers of requests or downloads.
In order to modify ASGARDs performance settings edit /etc/nextron/asgard2/asgard.conf
and restart the ASGARD service.
The default values are:
Value
Description
LoadConnMax=100
Max. concurrent „Busy Connections"
LoadStreamMax=25
Max. concurrent „Busy Streams"
PingRateMin=10
Polling Rate with 0 connected Assets (seconds)
PingRateMax=600
Polling Rate with 25000 connected Assets (seconds)
PingRateFast=5
Polling Rate for Assets in Fast Ping Mode (seconds)
These values should work fine in most scenarios – regardless of the size
of the installation. However, you may want to decrease PingRateMax
in order to achieve a better responsiveness of your ASGARD infrastructure.
While temporary stream overloads are quite normal, connection overloads
should not happen. If they do, either adjust your PingRateMax, your LoadConnMax or both.
ASGARD will indicate an overload with the "Connection Overload line"
and the "Stream Overload line" within the graphs in the overview
section (see picture below). If an ASGARD is in an overload situation
it will postpone connections and streams but will not lose or drop
tasks or be harmed in any way. ASGARD will recover to normal load automatically.
Stream overloads can happen temporarily (e.g. if you schedule a grouped
scan or grouped task with an unlimited rate). The picture below
shows such a normal overload situation that was caused by starting
a grouped scan with an unlimited rate. This is the expected behavior.
ASGARD will manage the load automatically and postpone streams until
the load has returned to normal.
The "Busy Streams" line indicates the number of streams currently active.
s you might have guessed, the picture above was taken on an ASGARD in
default configuration where the number of concurrent streams is set
to the default value of 25.
ASGARD will store all logs under /var/lib/nextron/asgard2/log/
All logs in this directory will be rotated and automatically cleared
after 14 months, please see Log Rotation and Retention for more information.
Please copy the oldest log packages to another directory or to a dedicated
log server in case you require longer retention periods.
Do not modify the built-in rotation settings as this might
interfere with ASGARD updates!
ASGARD will store all scan logs under /var/lib/nextron/asgard2/scan-results
All Scans will generate two files, thor-<ID>.txt.gz and thor-report-<ID>.html.gz.
The first file will be the raw THOR Scan Log(s) and the second file will be
the HTML Report(s). The numeric value in the file name is the Scan-ID, which
can be found in the the Scan Control view. Please make sure to enable the ID
column, since it is not enabled in the default view.
For Scans which were started with the --json flag, log files are
additionally placed in the scan-results directory and are named thor-<ID>.json.gz.
Please keep in mind, those JSON log files are not being transferred to
any connected Analysis Cockpit.
When ASGARD has a new agent version available you can see an indicator
on the Update menu item as well as on the sub menu Update > Agents.
There are two tasks to perform, updating the agents on your assets and
updating the agent installer for all future asset deployments.
If this is the first agent update performed on this ASGARD you might need
to enable the UpdateAgent module under Settings > Advanced > ShowAdvancedTasks.
Then you need to run the UpdateAgent module. You can do this on a per
asset basis by running a playbook from AssetManagement or create a
NewGroupTask from ResponseControl, which is the preferred way.
You can roll-out the update in batches by providing labels for each stage
or not select any label to perform the update on all assets.
The UpdateAgent module is not shown by default under (Group)
Tasks. To show the group task or single tasks (also inside the group task)
you need to select the UpdateAgent module from the Module
column. You may need to select the Module column from Columnvisibility
first, if not shown.
You need to update the agent installer as well, so that newly added
assets will directly use the current agent version. This is a manual
task as you might have customized your installers. If this is the case
you have to repack the agent installers as explained
in section Creating Custom Agent Installer.
If you use the default installer without any modifications you can run
the following command to update the agent installers:
nextron@asgard:~$ sudoasgard2-repacker
Or you can execute the agent installer update from within the WebUI at
Updates > Agents > RepackAgentInstallers at the bottom.
ASGARD supports creation of custom installers. Custom installers can be
configured in a way that agents show up with a preset label or with a
preset proxy configuration.
Go to Downloads > AgentInstallers > AddAgentInstaller.
Edit the properties of the desired installer and generate the installer
by clicking AddAgentInstallers. The installers are available at the
downloads page besides the default installers, so best use an affix as distinction.
You can also delete old Agent Installers which are not needed anymore. Just
select the Installer(s) and Click the Delete button in the top right corner.
Creating Custom Agent Installer From CLI (deprecated)
In order to create your custom ASGARD agent, save the current agents stored in
/var/lib/nextron/asgard2/installer/ to a directory of your choosing and run
sudoasgard2-repacker with one or more of the following flags:
-labelsstring
Add initial labels to clients comma separated list, e.g. [label1,label2,label3]
-proxiesstring
Proxies to be used by agents comma separated list, e.g. [proxy1.nextron:3128,proxy2.nextron:3128]
Example: In order to create an installer for servers that initially show up in
ASGARD with the label SQL-Servers use:
Your newly generated agents will show up in /var/lib/nextron/asgard2/installer
and will immediately be available for download from the login page. You can store
multiple custom agents under /var/lib/nextron/asgard2/installer/. In this case
all agents will be available for download from ASGARDs login page.
You can obfuscate the default asgard2-agent name with a custom one. The chosen name
will generate new agents which can be deployed to the endpoints. These agents will
create a service with the chosen name and will have no reference to ASGARD.
-namestring
nextron@asgard:~$ sudoasgard2-repacker-namejavax
This command will create a new agent for all operating systems.
This is specially designed for cases where an agent obfuscation is required.
An installed agent with the name "javax" would look like this:
All of our ASGARD servers come with predefined backup and restore scripts.
You can use them to keep a backup available in case something stops working.
Warning
If you are using a Management Center and Analysis Cockpit together, it
is advised to create the backups at the same time. This avoids
potential data inconsistencies across the two platforms. You can
do this via a cronjob on both systems or with an automation tool like
Ansible, Terraform, etc.
The same should be kept in mind when restoring your backups. You should
always restore the backups on all servers, to avoid getting problems
in the future.
The command asgard2-backup can be used to generate a backup of
all configurations, assets, tags, user accounts, tasks etc., except:
Log files (ASGARD, THOR)
Playbook results (collected evidence)
Quarantined samples (Bifrost)
nextron@asgard:~$ sudoasgard2-backup
Writing backup to '/var/lib/nextron/asgard2/backups/20200427-1553.tar'tar: Removing leading '/' from member namestar: Removing leading '/' from hard link targetsRemoving old backups (keeping the 5 most recent files)...done.
If you want to transfer the backup to a different system, make sure to copy the
.tar file to the home directory of the nextron user and change the permissions:
nextron@asgard:~$ sudocp/var/lib/nextron/asgard2/backups/20200427-1553.tar/home/nextron
nextron@asgard:~$ sudochownnextron:nextron/home/nextron/20200427-1553.tar
nextron@asgard:~$ ls-l
total 596496-rw-r--r-- 1 nextron nextron 309217280 Nov 1 12:01 20200427-1553.tar
After this is done, you can use scp or any other available tool to
transfer the backup file to a different system.
Hint
Our recommendation is to run the backup as a cronjob during a time, when
no tasks are running or are scheduled to run. The reason for this is that
our sample script will stop the ASGARD service before the backup to avoid any
inconsistency with the data.
Here is an example script and cronjob entry to create backups on a schedule:
1#!/bin/bash 2BACKUPDIR="/var/lib/nextron/asgard2/backups" 3NEWDIR="/home/nextron/backups" 4date
5 6echo"checking for destination folder" 7if![-d"$NEWDIR"];then 8mkdir$NEWDIR 9chown-Rnextron:$NEWDIR10fi1112echo"stopping asgard2.service"13if!systemctlstopasgard2.service;then14echo"could not stop asgard2.service, exiting script"15exit116fi1718sleep319echo"running backup script"20/usr/sbin/asgard2-backup
2122sleep323echo"starting asgard2.service"24if!systemctlstartasgard2.service;then25echo"could not start asgard2.service, needs manual debugging"26exit127fi2829echo"moving backup files to destination"30mv$BACKUPDIR/*.tar$NEWDIR31chown-Rnextron:$NEWDIR3233echo"backup created successfully"34echo""35echo""36exit0
The following crontab entry could be created to run the script every day at 2am.
You can edit the crontab of the root user with the following commands:
nextron@asgard:~$ sudosu
[sudo] password for nextron:root@asgard:~# crontab-e
Please keep in mind that the asgard2-backup script is only keeping 5
backups in place. If you want to change this, you have to change the value
GENERATIONS in the file /usr/sbin/asgard2-backup to a different value.
You can use the asgard2-restore command to restore a backup.
nextron@asgard:~$ sudoasgard2-restore
Usage: /usr/sbin/asgard2-restore <BACKUP FILE>nextron@asgard:~$ sudoasgard2-restore/var/lib/nextron/asgard2/backups/20200427-1553.tar
Stopping services... Removed /etc/systemd/system/multi-user.target.wants/asgard2.service.done.etc/nextron/asgard2/etc/nextron/asgard2/upgrade2.shetc/nextron/asgard2/run_asgard2.shetc/nextron/asgard2/server.pemetc/nextron/asgard2/ca2.keyetc/nextron/asgard2/pre_asgard2.shetc/nextron/asgard2/rsyslog-asgard-audit.confetc/nextron/asgard2/client.yaml...1+0 records in1+0 records out24 bytes copied, 3.2337e-05 s, 742 kB/sStarting services... Created symlink /etc/systemd/system/multi-user.target.wants/asgard2.service → lib/systemd/system/asgard2.service. done.
Note
The version of the ASGARD were the backup will be restored should
be the same as the version which was present while the backup was
created. If you need an older version of ASGARD, please contact our
support team.
The diagnostic package is an archive generated on ASGARD server to help
Nextron support engineers with the debugging of your problem. It contains
the system configuration and log data of an ASGARD instance.
You can generate a Diagnostic Package in SystemsStatus>Tab:Logs>DiagnosticsPackage.
The package can have a size that cannot be shared via Email. In this case you can either
ask us for an upload link (secure file sharing) or
remove big log files from the package (e.g. the file ./var/lib/nextron/asgard2/log/agent-access.log
is often responsible for 97% of the package size)
Edit the file asgard2-agent.yaml and set the value of write_log
to true. The file can be found in C:\Windows\System32\asgard2-agent\
or /var/lib/asgard2-agent/ for Windows and Linux/macOS, respectively.
write_log: true
After making these changes, restart the ASGARD service. You can then
find log entries and possible error messages in the file asgard2-agent.log
in the same directory as the configuration file.
Note: The value is set to false by default, because the agent
doesn't rotate or compress these logs. Leaving that value on true
could cause that file to grow very big and use a significant amount
of disk space. We recommend resetting it after the debugging session.
If Aurora does not behave like it should, e.g. using more resources
than you expected, you can create a diagnostics pack for our support
to help in troubleshooting the issue. This can be conveniently done
using the playbook [Default]CreateandCollectAuroraAgentDiagnosticsPack(Windows).
It can be run from AssetManagement > ResponseAction (Play button)
or from ResponseControl > Tasks > AddTask or if needed
as a group task. The resulting diagnostics.zip can be downloaded
from the third step in the PlaybookResult tab of the expanded task.
If you are seeing the DuplicateAssets view in your AssetManagement,
you need to fix the issue to avoid unwanted behavior of this asset. To
fix the issue, you need to uninstall the current ASGARD agent, delete the
configuration files, and redeploy a fresh copy.
To install the ASGARD Service Controller, please follow the
instructions in Service Controller Installation.
You need to wait a few minutes until the asset is connected to your ASGARD
before you continue with this step. Please note that you might need to accept the AssetRequest.
Using a web proxy with TLS/SSL interception will break the installation routine and shows this error:
Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown. Could not handshake: Error in the certificate verification.
Solution: Disable TLS/SSL interception for our update servers.
update3.nextron-systems.com
Used for THOR updates:
update1.nextron-systems.com
update2.nextron-systems.com
We do not support setups in which the CA of the intercepting proxy
is used on our ASGARD appliances.
The most common error is to define a simple hostname instead of a valid
FQDN during installation. This happens if no domain name
has been set during the setup step Network Configuration
(Domainname).
This leads to a variety of different problems.
The most important problem is that ASGARD Agents that install on endpoints
will never be able to resolve and connect to the ASGARD server.
The FQDN is set at installation time and is composed by the hostname
and the domain name. The ASGARD Agents require a resolvable FQDN to
correctly operate and connect to the ASGARD Server.
One of the processes which are executed at installation time include
the integration of the FQDN - which should be set during installation - into
the ASGARD agents. If we incorrectly set the FQDN or leave any of those
values empty, the agents will fail to connect to ASGARD.
With this fix we will set a new FQDN for the ASGARD Management Center, recreate
the internal certificates, and rebuild the agents.
Warning
The used FQDN in this manual is just an example. Please use the
FQDN of your domain. make sure the FQDN is resolvable via your DNS
server.
To set a valid FQDN for your ASGARD Management Center server, follow the steps below.
We are assuming that your local DNS server already has an A-Record assigned, so your
clients can resolve the new hostname/FQDN of your ASGARD Management Center.
Connect via SSH to the ASGARD Management Center:
user@somehost:~$ sshnextron@asgard-mc.example.org
Edit the hosts file. Please be careful with the changes in this file,
as this might make your system unusable!
nextron@asgard-mc:~$ sudoedit/etc/hosts
[sudo] password for nextron:
You need to change the following line (do not change the IP-Address!):
1127.0.0.1 localhost
2172.16.0.20 asgard-mc
34# The following lines are desirable for IPv6 capable hosts
5::1 localhost ip6-localhost ip6-loopback
6ff02::1 ip6-allnodes
7ff02::2 ip6-allrouters
To this (values are examples, please change accordingly!)
1127.0.0.1 localhost
2172.16.0.20 asgard-mc.example.org asgard-mc
34# The following lines are desirable for IPv6 capable hosts
5::1 localhost ip6-localhost ip6-loopback
6ff02::1 ip6-allnodes
7ff02::2 ip6-allrouters
Note
If you did not set a static IP-Address for your ASGARD Management Center
server, your IP-Address in the second line of the file might be 127.0.1.1.
This is due to your server using DHCP. It is advised that you are using a
static IP-Address. To change this, please see Changing the IP-Address.
You can verify if the changes worked. Run the following commands and see the difference
in the output:
If the first command shows the FQDN and the second one the hostname without domain,
your changes were set up correctly and you can continue to the next step.
We need to recreate the TLS certificate to make the Agent to ASGARD communication
possible again. Create a new file which will contain the script with the fix.
In this example we'll use nano as the text editor. Make sure that the system has
a valid FQDN.
nextron@asgard-mc:~$ nanofix-fqdn.sh
Insert the following content into the text editor:
1#!/bin/bash2exportFQDN=$(hostname--fqdn)34sed"s/\$FQDN/${FQDN}/"/etc/nextron/asgard2/server_cert_ext.cnf.in>/etc/nextron/asgard2/server_cert_ext.cnf
5opensslreq-new-nodes-subj"/O=Nextron Systems GmbH/CN=${FQDN}"-key/etc/nextron/asgard2/client-service.key-out/etc/nextron/asgard2/client-service.csr
6opensslx509-req-in/etc/nextron/asgard2/client-service.csr-CA/etc/nextron/asgard2/ca.pem-CAkey/etc/nextron/asgard2/ca.key-CAcreateserial-days36500-out/etc/nextron/asgard2/client-service.pem-extfile/etc/nextron/asgard2/server_cert_ext.cnf
7systemctlrestartasgard2
8asgard2-repacker-host$FQDN
After changing the variables to the desired values, save the file.
In nano this can be done in by pressing CTRL+X and confirming the changes with y.
Give the created script execution permissions and execute it:
You should now be able to reach the ASGARD Server via the new FQDN.
Navigate to https://<YOUR-FQDN>:8443, which reflects the FQDN we set earlier.
At this point you have to install the ASGARD agents on your endpoints again.
Remember to review the network requirements section to ensure all needed ports
are open to the ASGARD Management Center from your endpoints.
See Network Requirements
In some cases THOR fails to complete its scan and ASGARD reports the following error.
ASGARD noticed that the THOR scan failed
could not remove temp directory: remove C:\Windows\Temp\asgard2-agent\12fa35a6762a\thor\signatures\sigma\windows\file_event_win_webshell_creation_detect.yms:
The process cannot access the file because it is being used by another process. exit status 1
(scan result does not exist)
The most likely reason for this error is an Antivirus interaction. The Antivirus killed
the THOR process and still holds a handle to one of the signature files. The "THOR Launcher"
can only report that the process was terminated and that it isn't able to remove all files
because the Antivirus process still has that open handle on the file.
ASGARD ships with a self-signed certificate for its web interface
that expires after 182 days. If you do not use your own CA
infrastructure and want to renew the certificate or want to revert
from a broken state, you can recreate a self-signed certificate.
To do so log in using SSH and execute:
nextron@asgard:~$ sudoopensslreq-new-newkeyrsa:4096-days182-nodes-x509-subj"/O=Nextron Systems GmbH/CN=$(hostname--fqdn)"-keyout/etc/nextron/asgard2/server.key-out/etc/nextron/asgard2/server.pem
You need to restart ASGARD in order for the changes to take effect.
If you've lost the password of the local admin user (Web GUI) but
still have access the system via SSH, you can reset it via command
line using the following command.
nextron@asgard:~$ sudomysqlasgard-e"UPDATE users SET password = 'YmIc6P_6jdbeEL0HY4xIcpYstmM' WHERE name = 'admin';"
This resets the password to admin. You should then change that password immediately.
Reset Two Factor Authentication for a specific User
If you or another user lost their second factor (2FA) to log into the ASGARD Web UI,
you have to reset the users MFA Settings. If you cannot access the Web UI, use
the Command Line method.
There are two possible ways to reset TwoFactorAuthentication for a specific user.
We recommend to use the first option via the WebUI.
Log into ASGARDs Web UI as a user with administrative privileges.
Navigate to Settings > Authentication>Users and edit the user
you want to reset 2FA for. On the bottom of the popup you will see that
the 2FA option is enabled. Disable the option and click EditUser
(Leave everything else as it is; do not fill in a new password if not
necessary).
After you edited the user, the TwoFactorAuthentication will be disabled
and the user can log into ASGARD without 2FA.
Log into your ASGARD via SSH. You can reset the users MFA Settings with
the following command (in this example we assume that the user is called john):
nextron@asgard:~$ sudomysqlasgard--execute"UPDATE users SET tfa_valid = 0 WHERE name = 'john';"
Warning
This will disable the 2FA settings directly in the database. Please make sure
the command and especially the username is correct.
If you don't know the exact username for a user, you can use the following command
to get all the usernames and the 2FA status from ASGARD (if tfa_valid has a value
of 1, this means the user has Two Factor Authentication enabled).
nextron@asgard:~$ sudomysqlasgard--execute"select name,tfa_valid from users;"+----------+-----------+| name | tfa_valid |+----------+-----------+| admin | 1 || john | 0 || rickroll | 1 |+----------+-----------+
This command will also allow you to verify if the UPDATE command was successful (tfa_valid should be 0).
In some cases the timezone during the installation of the server
image might not be correct. To see if you have this problem in your
current installation, please log into your server and execute the following command:
nextron@asgard:~$ timedatectl
Local time: Mon 2022-10-24 09:52:03 BST Universal time: Mon 2022-10-24 08:52:03 UTC RTC time: Mon 2022-10-24 08:52:04 Time zone: Europe/London (BST, +0100)System clock synchronized: no NTP service: inactive RTC in local TZ: no
If you see that the Time zone is incorrect, follow the next steps to correct it.
List all the timezones with timedatectllist-timezones. If you want
to search for a specific Country/City, you can use grep, e.g. timedatectllist-timezones|grepPrague.
Now that you have the correct timezone you can set it the following way:
nextron@asgard:~$ sudotimedatectlset-timezoneEurope/Prague
nextron@asgard:~$ timedatectl
Local time: Mon 2022-10-24 10:56:45 CEST Universal time: Mon 2022-10-24 08:56:45 UTC RTC time: Mon 2022-10-24 08:56:46 Time zone: Europe/Prague (CEST, +0200)System clock synchronized: no NTP service: inactive RTC in local TZ: no
Please reboot the system after the changes have been made.
Warning
This might cause problems with existing Scheduled Scans!
In some environments, Aurora might generate a high amount of False
Positives. This should never be the case, since Aurora should only
alert on very few and mostly important findings. Most likely a rule
is matching on the environment and generates too many false positives.
To circumvent this, you can disable the rule and set a filter later on.
For Tuning, please see False Positive Tuning of Sigma Rules.
AMC#015: THOR License not valid yet (timezone difference)
Introduced Version
Fixed Version
<= 2.16.3
N/A
There is currently a bug in the ASGARD Management Center which
can can cause problems during THOR license generation. This happens
if the following conditions are given:
An asset which is located in a different timezone to your ASGARD Management
Center
The difference between the two timezones is greater than 8 hours.
If this is the case for a few assets of yours, you will encounter
the following error in your THOR scan:
The current workaround is to avoid issuing THOR licenses on your
ASGARD Management Center during a specific time window. We take
the time difference between your asset and your Management Center
and subtract 8 hours. The resulting time is the time window,
beginning at 00:00 AM local time of your Management Center, from
which you should avoid issuing licenses. Below are two examples:
ASGARD Management Center timezone: UTC +11
Asset timezone: UTC -3
This results in a time difference of 14 hours. We subtract 8 hours
from that and are left with 6 hours. That means you should avoid
issuing new licenses during the following time:
00:00 AM until 06:00 AM of the ASGARD Management Center local time.
If you have the following scenario, you will not encounter the problem:
ASGARD Management Center timezone: UTC +2
Asset timezone: UTC -3
The timezone difference is smaller than 8.
AMC#014: Edge Browser with translation, "removeChild" error
Introduced Version
Fixed Version
N/A
N/A
Microsoft's Edge Browser is changing DOM objects on web pages, when
the translator is activated. This leads to the following error on
some of our pages:
Since this is an issue with Microsoft Edge, we can not fix this.
You have to disable the translation tool of Edge to make the
pages functional.
AMC#013: Master ASGARD custom IOCs in Scheduled Group Scan
Introduced Version
Fixed Version
<= 2.15.3
2.15.5
Due to a bug in the handling of scheduled group scans in your Master ASGARD,
you will face an issue, were custom IOCs are not updated. This means that you would
use an old version of your custom IOCs for this specific scheduled group scan, even
if they have changed since the scheduled group scan was created. This scenario
happens if the following conditions are given:
Scheduled Group Scan on your Master ASGARD for one specific ASGARD
Your Custom IOCs changed after the scheduled group scan was created (compiled)
This led to the Master ASGARD not pushing the Custom IOC changes to the specific
ASGARD (which you created the scheduled group scan for), after your IOCs have changed
and your IOC Ruleset was compiled.
From version 2.15.5, you will receive the following warning, if you have a
scheduled group scan active with this bug:
Warning
Warning: Due to a bug in the Master ASGARD, some scheduled group scans
might not be affected by custom signature updates. We highly recommend
to stop and recreate the group scans with the following ids: 59
After you installed the version 2.15.5 or newer in your Master ASGARD and all
connected ASGARDs, make sure to fix any scheduled group scan which are being
reported by the above warning.
To do this, go to ScanControl > ScheduledGroupScans and activate the
ID column. Search for the specific scan with the reported ID.
Copy your THOR
Flags and disable the scheduled group scan. You can now recreate the scheduled
group scan with the exact settings and your target ASGARD. Afterwards, you can
activate the scheduled group scan again, this time no warnings will appear.
From this point onwards, any changes to your IOCs and IOC Rulesets within your Master
ASGARD will also be reflected on the ASGARD from your new scheduled group scan.
Repeat this step for any scheduled group scans which show in the warning message of
your Master ASGARD. Newly created scheduled group scans do not have this bug.
Due to a bug in the installer of our ASGARD Agent, there is a possibility that
the configuration file (asgard2-agent.yaml) gets renamed but not replaced
by a more current version. This usually happens if the agent installer is being
run a second time, after the agent is already installed. In some rare cases this
can also happen when the agent is being updated via your ASGARD. All together,
this leaves the agent in an undesirable state, which will cause no tasks/jobs
to be executed due to the missing config file (task will be in Pending state
or return an error).
You will find errors in the agent log (C:\Windows\System32\asgard2-agent\log\agent.log)
and also observe that the installer directory only contains asgard2-agent.yaml.old
and not the correct asgard2-agent.yaml config file.
2023/03/29 23:34:26 ASGARD_THOR: Error: could not load config: open C:\Windows\System32\asgard2-agent\asgard2-agent.yaml: The system cannot find the file specified.
2023/03/29 23:34:26 ASGARD_AGENT: Error: task 1350 done with error: exit status 1
Another indicator is the asgard2-agent-install.log file located at
C:\Windows\System32\asgard2-agent\. This almost always means the installer
was executed multiple times. See the two highlighted lines below, a normal install
would only contain the first line. Re-running the installer will produce lines 2
and 3, which indicate that the agent might be in the faulty state.
12023/03/30 16:13:14 installer arguments: asgard2-agent.exe -install
22023/03/30 16:13:14 could not open dst file C:\Windows\System32\asgard2-agent\asgard2-agent-service.exe: open C:\Windows\System32\asgard2-agent\asgard2-agent-service.exe: The process cannot access the file because it is being used by another process.
32023/03/30 16:13:14 could not copy files from executable path . to install path C:\Windows\System32\asgard2-agent: open C:\Windows\System32\asgard2-agent\asgard2-agent-service.exe: The process cannot access the file because it is being used by another process.
To get the agent up and running again, you need to rename the config file to its
original name and restart the asgard2-agent service. We wrote a little batch script
you can use, alternatively you can write your own and deploy it. Administrative
rights on the endpoint are needed.
1@ECHO OFF
2 3IFEXIST"C:\Windows\System32\asgard2-agent\asgard2-agent.yaml"GOTOnoFix 4IFEXIST"C:\Windows\System32\asgard2-agent\asgard2-agent.yaml.old"GOTOfixConfig 5 6:noFix 7echo config file exists, nothing to do
8GOTOcommonExit 910:fixConfig11echo stopping asgard2-agent service
12sc stop asgard2-agent
13timeout /t 5
1415echo config file in renamed state, fixing
16copy"C:\Windows\System32\asgard2-agent\asgard2-agent.yaml.old""C:\Windows\System32\asgard2-agent\asgard2-agent.yaml"17timeout /t 2
1819echo starting asgard2-agent service
20sc start asgard2-agent
21timeout /t 5
2223echo service should be in state RUNNING
24sc query asgard2-agent | findstr STATE
2526GOTOcommonExit2728:commonExit29exit
Hint
If you are seeing a second asset with the same hostname in your ASGARD, the issue was
most likely caused by re-installing the agent over an already installed agent. Try to
avoid running the installer a second time on systems which already have an agent installed.
You can find information when the installer was being run in the installer log
C:\Windows\System32\asgard2-agent\asgard2-agent-install.log.
When debugging GRPC connectivity issues between your components (for example Management
Center to Analysis Cockpit), you might encounter an error similar to the following one:
There is no workaround for this type of error. The error usually occurs because
one of the following things are preventing proper communication between your
components:
Firewall is using TLS Inspection
Proxy is using TLS Inspection
DNS Issues
Note
Your components expect specific certificates from each other when communicating.
If a device is trying to inspect TLS traffic, the certificate will change and
you receive the above error.
To help you figuring out what is causing the problem, you can try the following.
You can use openssl on your source system to see which certificate is presented
by the destination host (change the host and port values as needed).
nextron@asgard2:~$ openssls_client-hostcockpit3.domain.local-port7443CONNECTED(00000005)depth=0 O = Nextron Systems GmbH, CN = cockpit3.domain.localverify error:num=20:unable to get local issuer certificateverify return:1depth=0 O = Nextron Systems GmbH, CN = cockpit3.domain.localverify error:num=21:unable to verify the first certificateverify return:1write W BLOCK---Certificate chain 0 s:O = Nextron Systems GmbH, CN = cockpit3.domain.local i:O = Nextron Systems GmbH, CN = Analysis Cockpit 3---Server certificate-----BEGIN CERTIFICATE-----
The marked lines show you the certificate which is presented by the destination
host. If this certificate is different from the one you installed, then the problem
might be a device trying to do TLS Inspection.
We are currently working on improving the presented error message, to give
a better understanding what might be the issue at hand.
In some edge cases within restricted endpoint configurations,
you can encounter a problem which causes some agents to send
a lot of asset requests. This is mostly caused by hardened systems,
where the asgard agent is not able to write to its own configuration
file. One example is SELinux prohibiting write access to the needed
YAML file.
The asgard-agent process needs write access to the configuration file.
Make sure the following condition is present to avoid multiple asset
requests from the same endpoint:
Process
File
Permissions
/var/lib/asgard2-agent/asgard2-agent
/var/lib/asgard2-agent/asgard2-agent.yaml
Read/Write
Make sure to disable AutomaticallyacceptallAssetRequests in
the Advanced Settings in the meantime, to
avoid cleaning up after the changes to the endpoints have been made.
The file /var/lib/nextron/asgard2/log/agent-access.log is not included
in the logrotate configuration. This could cause a full disk after a certain
period of time, due to the file growing bigger and not being rotated.
To fix that problem you have to connect via ssh to your ASGARD Management Center
and edit the following file (as root user):
user@unix:~$ sshnextron@asgard
nextron@asgard:~$ sudoedit/etc/logrotate.d/asgard
[sudo] password for nextron:
You will see the contents of the asgard logrotate file. The entry on the bottom of
the file will be the one you need to change. Please make sure to only change the
following highlighted line:
You can save the file by pressing CTRL+O (you will be asked what File Name to write to,
you can just press Enter here). Exit the file by pressing CTRL+X.
Since the logrotate job will run every day at a certain time, the changes will take affect
with the next run. If you need to rotate the file immediately, run the following command:
You should see in your output something along the lines of the following:
rotating pattern: /var/lib/nextron/asgard2/log/agent-access.log after 1 days (14 rotations)
empty log files are not rotated, log files >= 10737418240 are rotated earlier, old logs are removed
considering log /var/lib/nextron/asgard2/log/agent-access.log
Now: 2023-02-13 10:10
Last rotated at 2023-02-13 10:00
log does not need rotating (log has been already rotated)
Search for rule title MaliciousPowerShellCommandlets, click on Update,
and deny the problematic update for this single rule by selecting Keepcurrentversion.
You can now update the rest of the ruleset using the UpdateAllRules button.
This will disable/skip the current update of the rule. As soon as a new update is
available, the rule will be shown again in the RuleUpdates view.
Note
Denying an update for a rule will only deny the current rule update. Any
future updates to this rule will be available again.
AMC#005: Basename Missing Operand after SSH Login
Introduced Version
Fixed Version
2.0.0
>=2.14.5
After logging into ASGARD Management Center via SSH right
after installing the base system, the following message can appear:
basename: missing operand
Try 'basename --help' for more information
It is caused by a unhandled condition in the MOTD (message of
the day) script that evaluates the version of the scanners and
signatures. After installing ASGARD it takes some minutes to
retrieve and install all scanners from the update servers.
You can build a new RPM package and use it for automated installations.
Log into the Asgard server which should be used by the clients to
connect to and execute the following steps:
nextron@asgard:~$ sudo-uasgard2-s# Open a shell with the access rights of the asgard2 userasgard2@asgard:~$ rpmbuild--targetx86_64--buildroot/var/lib/nextron/asgard2/templates/rpm/BUILDROOT/x86_64-bb/var/lib/nextron/asgard2/templates/rpm/SPECS/asgard2-agent-amd64.spec
Use the following file instead of the RPM from the Agent Download section in the Asgard UI:
When using scp to transfer the file from the server, you will
need to copy the file to a directory that is accessible by the
nextron user. You also need to change the file permissions.
One possibility to achieve this is to use the following commands:
There are rare cases where the package installation should be
automated and the command line flags are not an option. In this
cases it is possible to perform the ASGARD agent installation
manually. This requires to collect some files from ASGARD and
move them to the asset that should be connected.
# For 64-bit systems
/var/lib/nextron/asgard2/templates/linux/asgard2-agent-amd64
/var/lib/nextron/asgard2/templates/linux/client-amd64
# For 32-bit systems
/var/lib/nextron/asgard2/templates/linux/asgard2-agent-386
/var/lib/nextron/asgard2/templates/linux/client-386
# For all systems
/etc/nextron/asgard2/ca.pem
/etc/nextron/asgard2/client.yaml
These files have to be located on the target asset as follows
# Preparation if it is a first time installation
mkdir-p/var/lib/asgard2-agent/
# For 64-bit systems
mvasgard2-agent-amd64/usr/sbin/asgard2-agent-service
mvclient-amd64/var/lib/asgard2-agent/asgard2-agent
# For 32-bit systems
mvasgard2-agent-386/usr/sbin/asgard2-agent-service
mvclient-386/var/lib/asgard2-agent/asgard2-agent
# For all systems
mvca.pem/var/lib/asgard2-agent/ca.pem
mvclient.yaml/var/lib/asgard2-agent/asgard2-agent.yaml
# Make sure access rights in the file system are secure
chown-Rroot:root/var/lib/asgard2-agent
chmod-Rg-rwx/var/lib/asgard2-agent
chmod-Ro-rwx/var/lib/asgard2-agent
AMC#003: Error on newly installed Management Center
Introduced Version
Fixed Version
2.11.11
Open
You just installed an ASGARD Management Center and get error messages such as
Error: Something went wrong
c is null
or
Error: Something went wrong
Cannot read properties of null (reading 'forEach')
This happens if you want to initiate THOR scans or access THOR scan settings
before ASGARD was able to download the THOR packages from our update servers.
Make sure ASGARD is able to access our update servers
(see SystemStatus: Connectivity Test or SystemStatus > Diagnostics
and that you have imported a valid license (see Licensing).
You can either wait for ASGARD to download the THOR packages
automatically (check at Updates > THORandSignatures) or
initiate a download of THOR packages and signatures manually by
clicking the "Manually Check for Updates" button at Updates > THORandSignatures.
AMC#002: Aurora False Positive Filters Cleared After Saving
Introduced Version
Fixed Version
<2.14.5
>=2.14.5
If the global Aurora false positive filter at ServiceControl >
Aurora > FalsePositiveFilters is used, the text box is
empty/cleared after saving and refreshing the page.
If the false positive tuning you want to achieve is only affecting one rule, the best place to
tune it is a single rule false positive tuning at ServiceControl > Sigma > Rules and choosing
the "Edit false positives filters of this rule" action.
If you need global false positive filter, you can edit the file
/var/lib/nextron/asgard2/products/aurora-config/false-positives.cfg
directly via the ASGARD command line. In order for the changes to take effect it is important
NOT to click the ServiceControl > Aurora > FalsePositiveFilters > Save button.
Instead go to ServiceControl > Aurora > Configurations
and edit the configuration of the assets that need the false
positive filter. To do so just open the configuration using
the edit action and saving without any modifications using the
"Save Configuration and Restart Aurora Agents" button. This will
use the false positive filter defined in the file via CLI and
restarts the assets to use the new configuration.
AMC#001: API Documentation Curl Examples Not Working
Introduced Version
Fixed Version
2.12.8
>=2.13.5
The API documentation is not showing the API key
in example queries as it should and did.
You can find a simple script to install the ASGARD Agent via
Powershell. Place the installer and script in the same folder.
Change the script as needed.
1# Setting vars 2$scriptpath=$MyInvocation.MyCommand.Path 3$dir=Split-Path$scriptpath 4$installer="asgard2-agent-windows-amd64.exe" 5$servicename="asgard2-agent" 6 7# Checking if ASGARD Agent is already installed 8if(Get-Service-Name$servicename-ErrorActionSilentlyContinue){ 9Write-Host"ASGARD Agent already installed, exiting"10exit011}else{12Write-Host"ASGARD Agent not found, trying to install..."1314# Install ASGARD Agent15Start-Process-Wait-FilePath"$dir\$installer"-WorkingDirectory$dir-WindowStyleHidden-PassThru1617# Timeout just to make sure the service is up and running18Timeout/T151920# Checking service to see if agent was installed21if(Get-Service-Name$servicename-ErrorActionSilentlyContinue){22Write-Host"Installed ASGARD Agent successfully"23exit024}else{25$Host.UI.WriteErrorLine("Could not install ASGARD Agent")26exit127}28}
To deploy the ASGARD Agent (or any other .exe installer) via SCCM, you
have to write a Powershell script with a few conditions to mark an
installation correctly as successful or failed.
1# Get current directory 2$scriptpath=$MyInvocation.MyCommand.Path 3$dir=Split-Path$scriptpath 4 5# Run the installer 6$installer="asgard2-agent-windows-amd64.exe" 7Start-Process-Wait-FilePath"$dir\$installer"-WorkingDirectory$dir-WindowStyleHidden-PassThru 8 9# Timeout just to make sure the service is up and running10Timeout/T151112# If the service exists, the script writes console output and exits with code 013# If the service does not exist, the script writes an error output and exits with code 114# See https://learn.microsoft.com/en-us/mem/configmgr/apps/deploy-use/create-applications#about-custom-script-detection-methods1516$servicename="asgard2-agent"17if(Get-Service-Name$servicename-ErrorActionSilentlyContinue){18Write-Host"ASGARD Agent installed"19exit020}else{21$Host.UI.WriteErrorLine("ASGARD Agent not installed")22exit123}
Warning
This is just an example script which should work with SCCM.
If you encounter any problems, refer to the link provided
above for additional information.
SCCM Applications can also use a script to detect the Deployment.
You can use this part of the script to detect if the installation was successful:
1$servicename="asgard2-agent"2if(Get-Service-Name$servicename-ErrorActionSilentlyContinue){3Write-Host"ASGARD Agent installed"4exit05}else{6$Host.UI.WriteErrorLine("ASGARD Agent not installed")7exit18}
The ASGARD Agent folder has in a normal installation specific
permissions set. The ASGARD Agent checks regularly
for broken permissions and tries to fix them. If for some reason this
process fails, you have to check and change the permissions manually.
2023/03/31 12:02:35 ASGARD_THOR: Error: failed to repair permissions: set security info: Access is denied.
To do this we wrote a little PowerShell script which can help you with
this process. Please test the script before you deploy it in your
environment. To do this, you can leave the -WhatIf flag to see what
the script would do if the permissions are broken. If you are content
with the potential changes, remove the -WhatIf arguments. The script
needs administrative permissions.
1$asgardAgent="C:\Windows\System32\asgard2-agent" 2$asgardAgentTemp="C:\Windows\Temp\asgard2-agent" 3 4if(Get-Item-Path$asgardAgent|Get-Acl|where {$_.Access.IsInherited-eq$false}){ 5Write-Host"ASGARD Agent folder permission broken. Trying to fix: $asgardAgent" 6# Set the new Access Rule to inherit permissions 7$newAcl=Get-Acl-Path$asgardAgent 8$newAcl.SetAccessRuleProtection($false,$true) 9Set-Acl$asgardAgent-AclObject$newAcl-WhatIf10}11if(Get-Item-Path$asgardAgentTemp|Get-Acl|where {$_.Access.IsInherited-eq$false}){12Write-Host"ASGARD Agent folder permission broken. Trying to fix: $asgardAgentTemp"13# Set the new Access Rule to inherit permissions14$newAcl=Get-Acl-Path$asgardAgentTemp15$newAcl.SetAccessRuleProtection($false,$true)16Set-Acl$asgardAgentTemp-AclObject$newAcl-WhatIf17}18get-childitem-path$asgardAgent-Recurse-Depth1|Get-Acl|where {$_.Access.IsInherited-eq$false}|%{19$fullPath=Convert-Path$_.Path20Write-Host"ASGARD Agent folder permission broken. Trying to fix: $fullPath"21# Set the new Access Rule to inherit permissions22$newAcl=Get-Acl-Path$_.Path23$newAcl.SetAccessRuleProtection($false,$true)24Set-Acl$_.Path-AclObject$newAcl-WhatIf25}
Tip
After you changed the permissions of the asgard2-agent folder,
the agent might correct the permissions again and set them accordingly.
Only use this script if the agent is showing errors that permissions
can not be set.
If you want to implement the ASGARD Agent into your Golden Image, you
can do this by following the steps in this section. Make sure to download
the right Agent Installer package from your ASGARD.
You have two options to deploy an Agent on your Golden Image, with the
first one being the easier method.
Before continuing, make sure the host can't reach your ASGARD.
In this method we make sure that the host system, which is being prepared
for the Golden Image, is either offline or can't reach the ASGARD. Go ahead
and install your ASGARD agent as you do normally. Once the installation is
done, you can stop the asgard2-agent service.
You ASGARD Agent should be ready now. You have to make sure that the Agent
is not communicating with your ASGARD during the whole process. If the agent
is for some reason communicating with the ASGARD and creating an Asset
Request, make sure that you stop the asgard2-agent service again and
inspect the following file:
The file should not contain the marked lines in the next example. If both lines
exist, make sure you delete them and save the file. Make also sure to deny the
Asset Request in your ASGARD to avoid confusion:
Your Golden Image will not work if the two lines in the asgard2-agent.yaml
file exist, it instead will create a DuplicateAsset. So make sure that
they are not present when you are creating the Golden Image!
If for some reason you can not prevent your host, which is being used for
the Golden Image, to communicate with your ASGARD, then follow the next
steps. Go ahead and install your ASGARD agent as you do normally. Once the
installation is done, you can stop the asgard2-agent service.
Once the service is stopped, we have to alter the configuration file of the
agent. This is necessary because your agent will have communicated with your
ASGARD by now, thus having generated an token, which should be unique.
If you would create your Golden Image now, you would have the
systems, installed with the Golden Image, appear as DuplicateAsset (see
Duplicate Assets Remediation).
Open the asgard2-agent.yaml file and delete the marked lines in our example.
After you deleted the two lines and saved the file, your host is ready. Make
sure those two lines are not present, as well as your asgard2-agent service
is still not running. We delete the token because it is unique to ASGARD.
If two agents are presenting the same token, they will be flagged as duplicate
assets. The registered value tells the agent if it has to send a new asset
request or not. Once it is set to true it would not send a new request.
Hint
Make sure to deny the Asset Request, which we just created while installing
the agent on our host, in ASGARD. This is to avoid confusion down the road.
Install TLS certificates on ASGARD and MASTER ASGARD
There are several methods to sign the ASGARD generated CSR
request. This section describes the two most common procedures.
Use Case 1 - CSR Signing with a Microsoft Based CA
Open the Certificate Authority snap-in within Windows Server
certsrv – Microsoft Certification Authority Main Page
Right click your CA >> All Tasks >> Submit new request
Use Case 2 - CSR Signing with an OpenSSL Based CA
Warning
In order to avoid security warnings [1] on some browsers, the CA signing
process needs to ensure to copy all Subject Alternative Name (SAN) from the CSR to the signed Certificate.
There are two ways of doing this while singing the CSR via openssl.
The first method of including all extensions from the CSR to the new certificate,
is via the openssl.cnf file, by uncommenting the copy_extensions attribute.
The location of the openssl.cnf file depends on your system. On our test system, this
file was located at /etc/pki/tls/openssl.cnf.
Warning
Please make sure to comment the line out again once you are done with singing
your CSR.
Example:
80####################################################################
81 [ CA_default ]
82 83 dir = ./demoCA # Where everything is kept
84 certs = $dir/certs # Where the issued certs are kept
85 crl_dir = $dir/crl # Where the issued crl are kept
86 database = $dir/index.txt # database index file.
87 #unique_subject = no # Set to 'no' to allow creation of
88 # several certs with same subject.
89 new_certs_dir = $dir/newcerts # default place for new certs.
90 91 certificate = $dir/cacert.pem # The CA certificate
92 serial = $dir/serial # The current serial number
93 crlnumber = $dir/crlnumber # the current crl number
94 # must be commented out to leave a V1 CRL
95 crl = $dir/crl.pem # The current CRL
96 private_key = $dir/private/cakey.pem # The private key
97 98 x509_extensions = usr_cert # The extensions to add to the cert
99100 # Comment out the following two lines for the "traditional"
101 # (and highly broken) format.
102 name_opt = ca_default # Subject Name options
103 cert_opt = ca_default # Certificate field options
104105 # Extension copying option: use with caution.
106 copy_extensions = copy
107108 [...]
The second method of including all extensions from the CSR to the new certificate,
is via an extension file (for example asgard-test01.ext) containing all your subjectAltName entries.
This tells openssl to use a extension for signing the CSR. In our case the extension contains a list of
subjectAltName values.
To do this, place a file with your subjectAltName entries in the same folder of your CSR. The contents of this file
look something like the following example. Values after subjectAltName= should be equal to the
values of your CSR:
root@ca:~# catasgard-test01.ext
subjectAltName = DNS:asgard-test01.nextron, IP Address:172.28.28.101
The content should be identical to the values you set in your CSR. You can
inspect those with the following command:
root@ca:~# opensslreq-inasgard-test01.csr-noout-text[31/146]Certificate Request: Data: Version: 1 (0x0) Subject: C = DE, ST = Hesse, O = Nextron, OU = Security IT, CN = asgard-test01.nextron Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (4096 bit) Modulus: 00:cb:74:c9:ed:4e:4d:db:39:7b:e0:dc:bb:55:d6: [...] c2:9f:69 Exponent: 65537 (0x10001) Attributes: Requested Extensions: X509v3 Subject Alternative Name: DNS:asgard-test01.nextron, IP Address:172.28.28.101
Prepare the CA certificate, CA private key and the certificate signing request (and optionally your extension
file, if you chose method 2).
Execute/adapt the following command depending on the method you chose before:
First method:
root@ca:~# opensslca-certcacert.pem-keyfilecakey.pem-inasgard-test01.csr-outasgard-test01.crt-days3650Using configuration from /etc/pki/tls/openssl.confEnter pass phrase for cakey.pem:
root@ca:~# opensslca-certcacert.pem-keyfilecakey.pem-inasgard-test01.csr-outasgard-test01.crt-days3650-extfileasgard-test01.ext
Using configuration from /etc/pki/tls/openssl.confEnter pass phrase for cakey.pem:Check that the request matches the signatureSignature okCertificate Details: Serial Number: 1 (0x1) Validity Not Before: Feb 23 09:58:10 2023 GMT Not After : Feb 20 09:58:10 2033 GMT Subject: countryName = DE stateOrProvinceName = Hesse organizationName = Nextron organizationalUnitName = Security IT commonName = asgard-test01.nextron X509v3 extensions: X509v3 Subject Alternative Name: DNS:asgard-test01.nextron IP Address:172.28.28.101Certificate is to be certified until Feb 20 09:58:10 2033 GMT (3650 days)
This document will guide customers with an existing ASGARD
version 1.x to perform an agent migration to ASGARD version 2.x.
The new release of ASGARD Management Center brings not only
a redesigned interface, but also major changes in the architecture
and usability, making it faster, more robust and easier to use.
You will find all new agents under /var/lib/nextron/asgard2/installer,
this example will cover a migration of a windows x64 system. Please see
the following chapters for Linux/macOS hosts.
Open your ASGARD version 1.x web interface and navigate to the
ResponseControl view. You will be prompted for a username and password,
use the same login information as you use to log into ASGARD.
Once you reach the Response Control Section (GRR) please navigate
to the top right corner (settings gear) and switch to the
Advanced Mode. Apply the settings.
After approximately 10 minutes, the binary will be executed and
installed on the selected system. The status can be retrieved by
navigating to the Managelaunchedflows section on the left menu.
Save this script in your ASGARD v1.x and sign/upload it to GRR as
described in section Sign the new agents
, afterwards you will be able to launch a HUNT to your connected Linux Systems.
Note
Please bear in mind that the above script will work only for
Ubuntu/Debian systems and needs to be adapted for Redhat/CentOSsystems.
Save this script in your ASGARDv1 and sign/upload it to GRR as
described in section Sign the new agents,
afterwards you will be able to launch a HUNT to your connected macOSSystems.
This section will cover frequent questions regarding the migration.
Will there be any problem running both agents (v1, v2) at the same time?
There are no known issues running both agents at the same time.
The new ASGARD v2 agent is more lightweight and has better performance.
The expected RAM utilization in idle mode demonstrated in our tests puts
the new agent in a very good position, consuming only 1 MB.
Will I need more resources for my new ASGARD v2 server?
Please refer to Hardware Requirements for specific sizing.
The overall tests performed highlight that both, server and agents, have better
performance, which will allow more agents to be management per ASGARD (compared to version 1).
Can I import my memory dumps and file collections made on ASGARD v1?
Unfortunately, importing memory dumps and/or file collections made on ASGARD v1 is not possible.
Added uuids to tables like THOR scans, Aurora services, group tasks and many more
Change
Improved license generation for assets, THOR and Aurora. Licenses will no longer be max. valid for 90 days. Instead, they are valid as long as the ASGARD license. We also added a small tolerance that allows you to slightly exceed the license limit.
Security
OS Security Fix
Bugfix
Fixed issues with regenerating IOC rulesets for scheduled group scans (Master ASGARD only)
Bugfix
Fixed an ASGARD license issue in combination with Master ASGARD and Broker Network
Master ASGARD must be upgraded before upgrading the connected ASGARDs
Release Date
Tue, 12 Apr 2022 15:18:00 +0200
Type
Description
Feature
Support Aurora Agent
Feature
THOR progress bar - A progress bar in the scan table that shows the current progress of the THOR scan. On hover, you can see a detailed view of the progress
Feature
AIX Support (Beta only)
Feature
Collect JSON THOR Log (optional)
Feature
Alternatively manage iocs with files instead of ioc groups
Feature
Added 'THOR 10 Latest' option to THOR download page
Feature
New product "Aurora Signatures"
Feature
New section 'Playbook Files' that lists all files that are available for playbook steps. This section also supports downloading, deleting and uploading files.
Feature
New tab 'Diagnostics' that lists all components with their status
Feature
New loading bar when refreshing tables
Feature
Custom IOC rulesets and MISP rulesets support for Aurora Agent
Feature
The Master ASGARD can now generate THOR download links and provide a License API, too
Feature
Added 'Auto Refresh' to most tables that can automatically refresh the table in a specified interval
Feature
Show total ram and disk usage in overview page
Feature
New filter 'Show all / show active only' in Service Control
Feature
Show which scheduled group scans are affected when compiling or deleting custom IOC rulesets or MISP rulesets
Feature
When adding new scans with custom IOC rulesets, a warning will be shown if a ruleset contains uncompiled changes
Feature
Single Scans and Single Tasks can now be created in Scan Control and Response Control with the 'Add Scan' / 'Add Task' buttons
Feature
Show warning if automatic THOR Signature updates are disabled and the currently used THOR Signatures are outdated
Feature
Show warning if ASGARD license expires soon
Feature
Show warning if a configured scheduled group scan is running with an outdated THOR version
Feature
Added ntp to services in settings section
Feature
Custom max. runtime for scans and tasks
Feature
Added API endpoints 'Add Playbook File' and 'Search Playbook Files' to API documentation
Feature
In the Downloads > THOR > Download Token section, the latest usage of the download token will be shown
Feature
New Sigma response flag "lowprivonly" that applies responses only on processes with low privileges
Feature
Logging time stats and network traffic of Master ASGARD synchronization
Feature
Show services that use ioc / misp / sigma ruleset when compiling / deleting ruleset
Feature
Show number of assets per service configuration
Feature
Show pending changes, available revision and running revision in service table
Feature
"Available since" and "Used since" in THOR / THOR Signatures and Aurora products table
Feature
Show warning if selecting all entries in a table but table has more than 1 page
Feature
Test proxy
Feature
Show TLS information
Feature
Show NTP information
Feature
Recommended response actions for Sigma
Feature
Added success notifications in UI
Feature
The version of the used Aurora Agent can now be pinned per service configuration
Feature
Completely refactored agent installer section. Added more information like asset labels and proxy and added repacker buttons per installer.
Change
Removed the 'is directory' property in playbook steps. There will be no difference anymore between files and directories when collecting a filepath or directory
Change
Completely refactored the API documentation, the API itself has not been changed
Change
Cosmetics
Change
Wordings
Change
Added a lot more tooltips and information
Change
Other smaller UX stuff
Change
Improved performance between Master ASGARD and ASGARD
Change
Table columns are not clickable anymore, use the expand button in the first column instead
Change
Added hostname of ASGARD to CSR generator
Change
Playbook steps can now be managed in the right sidebar instead of the expanded table row in the playbook table
Change
Separated playbooks in 'new task' dialog into 'pre-installed' and 'custom'
Change
When adding new scans or creating THOR download links, the latest THOR version will automatically be selected in the dialog
Change
Changing a THOR or Signature version manually will now disable the auto update, auto update can now be activated in the 'set version' dialog, too
Change
Added fallback logic for missing THOR versions - e.g. scan with 10.5 if 10.6 was not found
Change
Creating a Sigma ruleset with "Auto Config" will now add all existing rules that match the config to the ruleset
Change
Security Fix - Updated TLS cipher suite
Change
Upgraded winpmem
Change
The asset view per service is now splitted into two tabs, one with already deployed services and one with non-deployed services
Change
Hiding LogWatcher per default if LogWatcher has not been used yet
Bugfix
Added info that filename iocs are not case insensitive if applied as regex
Bugfix
Fixed reset of MISP form data on error
Bugfix
Fixed adding users without role
Bugfix
Fixed missing ntp restrictions in ntp config
Bugfix
Fixed performance and stability of MISP event synchronization
Bugfix
Automatically refresh the UI if the UI version differs from server's UI version
Bugfix
Some collected Aurora or LogWatcher events were corrupt
Bugfix
Fixed synchronization issues between Master ASGARD and ASGARDs caused by time sync issues
Bugfix
Fixed non-working 'Agent Update Available' and 'Service Controller Update Available' indicators on Master ASGARD
Bugfix
Added autoremove to upgrade routine to prevent issues with boot partition
IMPORTANT: Please read before you upgrade your ASGARD!
The upgrade can take up to one hour in large installations, do not reboot during installation
The API has been revised. This will potentially break existing API integrations
Master ASGARD must be upgraded before upgrading the connected ASGARDs
To enable new Service Control section add Service Control right to respective roles (Settings > Roles)
Existing group scans will be stopped and can not be restarted or resumed and must therefore be recreated
Scheduled group scans will continue working unless custom IOCs are in use. If custom IOCs are in use, scheduled group scans must be stopped and recreated in order to function properly
The IOC Management has been completely revised. Existing custom IOCs will be deactivated and can be found and downloaded at /var/lib/nextron/asgard2/iocs/. Re-upload your existing custom IOCs through our new UI at Scan Control > IOC Management
Type
Description
Feature
Refactored and improved UI
Feature
Improved performance of tables on the UI
Feature
Updating the search in a UI table will now cancel the previous query instead of detaching the previous query in the background
Feature
A Service Controller Agent is now available to be installed in addition to the existing agent. It can be used to run services instead of one-shot tasks.
Feature
Added new service 'Log Watcher' that scans the Windows EventLog in real-time, based on Sigma Rules that are managed on the Management Center
Feature
Multiple THOR minor version can now be managed and used for Scan tasks
Feature
THOR flags in UI are now based on the selected THOR version
Feature
CPU-, RAM- and DISK-usage are now automatically refreshing in UI every second
Feature
New ASGARD status light in UI (green = no overload, yellow = temporary overloaded, red = overloaded)
Feature
CSV exports now contain more information, added CSV export to many more tables
Feature
ASGARD can now handle multiple licenses
Feature
Licenses for archived assets are invalidated after 3 month and the license count is reduced accordingly
Feature
Scans in the scan table now contain the exact THOR version and signature version that has been used for scanning
Feature
THOR scans are now terminated more gracefully to improve error handling
Feature
Completely refactored IOC Management
Feature
Improved LDAP settings and testing options
Feature
The asset timeline is now available on Master ASGARD
Feature
Repack agent installers from UI
Feature
MacOS ARM64 Support
Change
Requirements for password complexity has been increased
Change
The group task engine has been refactored to issue tasks asynchronously in background instead of synchronously on agent pings
Change
The single task table now only shows tasks that haven't been issued by a group task
Change
Improved security by adding more strict http headers to UI
Change
The Master ASGARD now requires that all connected ASGARDs are at least version 2.11.0
Change
Regenerated ASGARD's certificate for agent communication with SAN extension
Change
The agent stream API now terminates streams that are inactive for over 10 minutes
Change
Added more retries and pauses to the agent functions to handle issues with EDRs and AVs
Change
Improved performance by removing some mutexes and using more specific mutexes for critical data
Change
Master ASGARD now synchronizes scanners and signatures with the connected ASGARDs
