The new "Multiple logons by the same user from different workstations" rule helps you capture situations where a set of credentials is shared by a group of people or has been stolen by an attacker and is being tried on multiple computers at once. These incidents are tricky because they slip through the cracks if you are only focusing on individual workstations. The rule is based on making the InTrust server analyze incoming audit data from multiple monitored computers.
To minimize false positives, the rule comes with a flexible set of parameters that let you fine-tune the analysis, including the logon types you want to watch for.
The rule is located in the Advanced Threat Protection | Windows/AD Suspicious Activity | Gaining User Access | Suspicious logons rule folder.
The Exchange auditing capabilities of InTrust have been extended to Exchange Server 2019.
The Knowledge Pack for Solaris has been rebuilt for this version of InTrust, and you don't need to get it from a previous version anymore.
This InTrust release does not include HP-UX related components or configuration items. It is not expected that future versions will provide them.
In earlier versions of PowerShell, the logging facilities were inferior to the recent versions. Therefore, a common attack strategy is to use an old version of PowerShell in order to prevent logging of malicious activity. This rule informs you about such threats. For details, see Monitoring for PowerShell Downgrades. The rule is located in the Advanced Threat Protection | Windows/AD Suspicious Activity | PowerShell rule folder.
This rule captures situations where a powerful account logs on to a workstation in ways that are vulnerable to pass-the-hash attacks, which are based on retrieval of credentials from memory or cache. The rule is located in the Advanced Threat Protection | Windows/AD Suspicious Activity | Gaining Administrative Rights rule folder.
The rule detects launches of suspicious processes, meaning processes that are started from unusual locations or generate events containing telltale keywords. As the name suggests, the rule relies on the Secuity log. The rule is located in the Advanced Threat Protection | Windows/AD Suspicious Activity | Backdoors rule folder. For details, see Setting Up Monitoring for Suspicious Processes.
The range of VMware systems that InTrust can audit has been extended to include ESXi 6.0, 6.5 and 6.7.
Event Log Recipient is a new type of notification recipient (formerly, operator) that makes it possible to use Windows event log as the notification destination. If this recipient is specified for a real-time monitoring rule, then InTrust generates an event about how the rule was matched and includes alert data. At this time, these events are written only to the InTrust log. You can use it to integrate InTrust alerts into your SIEM security log analytics workflow. Alerts provide the focus that you don't get by streaming everything into your SIEM.
For more details, see Example: Mirroring InTrust Real-Time Alerts in SIEM. For convenient batch configuration of rules, see Quest Support Knowledge Base article 312739.
The Syslog message format defined by RFC 5424 is widely supported by SIEM providers. Now that InTrust can forward events in this format, you can easily integrate your InTrust-collected data with a variety of SIEM solutions, without the need for custom scripts implementing proprietary formats.
Event forwarding over TCP can now be secured with TLS in environments where this type of security is used. TLS-Secured TCP is a new transport option in the forwarding settings for InTrust repositories.
Unlike previous releases where you used one event forwarding filter per repository, you can now specify multiple filters. InTrust will forward events that match any of the filters you select. Each filter you add broadens the scope instead of narrowing it.
InTrust provides a set of event forwarding filters that incorporate security analysis best practices. These filters incorporate recommendations from such sources as NSA and MITRE and categorized so that you can easily combine them as necessary.
The filters are customarily implemented as searches and are available in the Threat Hunting | Windows | Native OS Logs Telemetry search folder.
InTrust components can be installed on computers running Windows Server 2019. InTrust configuration, audit and alert databases can be hosted on Microsoft SQL Server 2017.
The InTrust SDK now provides bindings for working with sites and event forwarding configuration.
The new "Potential password spraying (multiple failed logons for valid accounts)" rule captures situations where an attacker tries multiple user names in a row with the same password, circumventing the built-in account-locking mechanism.
The rule complements the existing multiple logon failure rules and is located in the Advanced Threat Protection | Windows/AD Suspicious Activity | Gaining User Access | Brute-force attacks rule folder.
This release does not contain any changes to the Knowledge Packs for Solaris and IBM AIX, therefore these components were not rebuilt for InTrust 11.4.1. If you need InTrust configuration objects related to these platforms and InTrust agents for them, use previous versions of these components. Do one of the following:
The new "Suspicious PowerShell activity" and "Suspicious PowerShell Core activity" rules help minimize the impact of attacks based on PowerShell scripts. InTrust lets you thwart PowerShell-wielding attackers by setting up alerts and emergency response actions for whenever someone uses suspicious PowerShell commands. These rules watch for telltale traces of potentially dangerous PowerShell activity, so they rely on PowerShell logging. For details about this real-time monitoring scenario, see Setting Up Monitoring for Suspicious PowerShell Activity.
The event forwarding engine has been redesigned from the ground up to enable support for TCP and make forwarding more robust and extensible. TCP is now available along with UDP as the transport for audit data transmission. It ensures guaranteed delivery of forwarded events.
This release lays the groundwork for InTrust self-auditing. With this initial implementation, you can keep track of the connections that your InTrust servers and agents make and accept. In addition to its own value, this data helps achieve compliance with regulations regarding auditing systems. For details, see Self-Auditing in InTrust.
© ALL RIGHTS RESERVED. Términos de uso Privacidad Cookie Preference Center
