Loading
1. NEW AND IMPROVED
1.1. API for interaction with Labyrinth Deception Platform
We added a REST API to obtain the necessary data when working with Labyrinth Deception Platform. Currently, the following information can be obtained using this interface:
In the subsequent releases, we plan to expand the functionality of this API.
After the update, a detailed description of the REST API is available here:
https://appliance_ip/api/v1/documentation
Authentication to access this interface is performed using an API token that is generated for the user in Settings -> Users.
The token can be generated:
Generating a token by an ordinary user involves the following sequence of actions:
A token is available for viewing only once. Therefore, once the modal window with the token is closed, it cannot be viewed again. Therefore, saving this token in a safe and secure place is necessary.
Each user can have only one token. If the token creation procedure is started again as described above, the old token will be invalidated.
To generate a token for another user, you need:
Only users with the Administrator role or Superusers can generate tokens for other users.
1.2. MITRE ATT&CK® Matrix mapping
The system's alert information is supplemented by a description of the attacker's actions using the tactics and techniques described in the MITRE ATT&CK® matrix.
Techniques and tactics that appear in the alert description are links to the official MITRE website, where you can read a detailed description of a particular tactic or technique.
If SIEM integration is enabled and configured, information about tactics and techniques is also added to the CEF message.
Currently, alert compliance with MITRE ATT&CK® matrices covers a specific list of tactics from ATT&CK for Enterprise and ICS.
The MITRE ATT&CK® for Enterprise list includes the following tactics:
The techniques and sub-techniques include the following:
Tactics and techniques that correspond to the MITRE ATT&CK® for ICS matrix:
1.3. Improved CEF message data for SIEM integration via syslog
If the SIEM Integration (Syslog forwarder) integration is enabled in theintegations settings, alerts and the Audit Log are sent to the SIEM in CEF format.
This release adds information about the information sent to the SIEM:
For example,
CEF:0|Labyrinth Technologies|Point|0|LAB_ALERT|RCE detected|10|src=192.168.200.228 dst=172.16.72.103 pointType=uweb_comments_test honeynetID=honeynet01 location=labdev dvc=172.16.72.103 dvchost=sierra deviceExternalId=universalweb-a6f05252 cs3=TA0008 cs3Label=Tactic cs4=T1210 cs4Label=Technique cs1=Remote Code Execution attempt has been detected cs1Label=Description cs2=Identify the host of the source IP. Check previous activity from source IP. Recommendation: continue monitoring activity from source IP. cs2Label=Playbook
1.4. Information about the username you are creating or editing
Information about the user's username being created or edited has been added to the Audit Log records sent to the SIEM. Prior to this release, this information could only be obtained from the Labyrinth web interface.
Currently, the audit log sent to the SIEM is extended and looks like this:
CEF:0|Labyrinth Technologies|Tenant|0|LAB_AUDIT|add_new_user|10|src=172.16.254.2 event_type=add_new_user tenant=bubble username=vlakas target_username=test_user event_status=success
1.5. WAF for Universal Web Point
A full-fledged Web Application Firewall has been added to Universal Web Point to detect the types of attacks more accurately on the Point itself, including both OWASP Top 10 and other vulnerabilities.
At the same time, the detected attacks do not affect the web application with which the Point is associated.
WAF uses the OWASP® Core Rule Set (CRS) to detect attacks, a set of rules for detecting common attacks on Web applications and includes, among other things, the OWASP Top Ten.
The categories of detection rules include the following:
1.6. Expanding Universal Web Point configuration options
The list of updates includes the expansion of Point settings and includes the following:
You can add your TLS certificate and the key that will be used for HTTPS.
By default, when launching a Universal Web Point, a self-signed certificate is used, which is generated automatically based on the certificate parameters of the original web application.
Currently, you can set your TLS certificate and key directly in the configuration.
In the Universal Web Point configuration, you can set the settings to limit the intensity of requests, which reduces the overall load on the host specified in upstream_url.
It is possible to add URL paths that are not present in the original web application. For example, the original web application does not have /robots.txt, and Universal Web Point can respond to such requests with specific content.
For example:
services:
http:
upstream_url: https://labyrinth.tech
server_name: labyrinth.tech
service_type: iis
server_banner: The latest MS IIS
headers:
X-Powered-By: "ASP.NET"
routes:
- path: /robots.txt
module: text
methods:
- GET
contents: |
User-agent: *
Disallow: /admin
Disallow: /cabinet
Disallow: /error/
All of the above examples are for illustrative purposes only and may not be accurate. Please refer to the Universal Web Point configuration documentation for specific configuration options.
1.7. Improvements to ClientOS
ClientOS is a type of Point that simulates user actions on the network. For example, it makes HTTP/S, NetBIOS, DNS, and other requests for services specified in the Point configuration at a specific frequency, which can be configured in a new release.
For example:
services:
arp_spoofing:
enable: true
dns_client:
enable: true
records:
- www.bing.com
- sls.update.microsoft.com
- v10.vortex-win.data.microsoft.com
- _ldap._tcp.dc._msdcs.WORKGROUP.localdomain
- detectportal.firefox.com
timeout: 10
timeout_shift: 5
http_client:
enable: true
verify_tls: false
user_agent: "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36"
urls_list:
- http://detectportal.firefox.com/canonical.html
- https://profile.accounts.firefox.com
- https://token.services.mozilla.com
- https://api.accounts.firefox.com
timeout: 60
timeout_shift: 5
Thus:
For example, if timeout = 60 and timeout_shift = 5, the next request may be made not exactly in 60 seconds, but, for example, in 61, 65, 63, etc. seconds.
All of the above examples are for illustrative purposes only and may not be accurate. Please refer to the ClientOS Point configuration documentation for specific configuration options.