Blog

No items found.

The VR Goldilocks Problem and Value of Continued Recognition

Default blog imageDefault blog imageDefault blog imageDefault blog imageDefault blog imageDefault blog image
04
Mar 2019
04
Mar 2019
Security and Operations Teams face challenges when it comes to visibility and recognition. Learn more about how we find a solution to the problems!

First, some context about VR

Security Operations teams face two fundamental challenges when it comes to 'finding bad'.

The first is gaining and maintaining appropriate visibility into what is happening in our environments. Visibility is provided through data (e.g. telemetry, logs). The trinity of data sources for visibility concern accounts/credentials, devices, and network traffic.

The second challenge is getting good recognition within the scope of what is visible. Recognition is fundamentally about what alerting and workflows you can implement and automate in response to activity that is suspicious or malicious.

Visibility and Recognition each have their own different associated issues.

Visibility is a problem about what is and can be generated and either read as telemetry, or logged and stored locally, or shipped to a central platform. The timelines and completeness of what visibility you have can depend on factors such as how much data you can or can't store locally on devices that generate data - and for how long; what your data pipeline and data platform look like (e.g. if you are trying to centralise data for analysis); or the capability of host software agents you have to process certain information locally.

The constraints on visibility sets the bar for factors like coverage, timelines and completeness of what recognition you can achieve. Without visibility, we cannot recognize at all. With limited visibility, what we can recognize may not have much value. With the right visibility, we can still fail to recognise the right things. And with too much recognition, we can quickly overload our senses.

A good example of a technology that offers the opportunity to solve these challenges at the network layer is Darktrace. Their technology provides visibility, from a network traffic perspective, into data that concerns devices and the accounts/credentials associated with them. They then provide recognition on top of this by using Machine Learning (ML) models for anomaly detection. Their models alert on a wide range of activities that may be indicative of threat activity, (e.g. malware execution and command and control, a technical exploit, data exfiltration and so on).

The major advantage they provide, compared to traditional Intrusion Detection Systems (IDS) and other vendors who also use ML for network anomaly detection, is that you can a) adjust the sensitivity of their algorithms and b) build your own recognition for particular patterns of interest. For example, if you want to monitor what connections are made to one or two servers, you can set up alerts for any change to expected patterns. This means you can create and adjust custom recognition based on your enterprise context and tune it easily in response to how context changes over time.

The Goldilocks VR Matrix

Below is what we call the VR Goldilocks Matrix at PBX Group Security. We use it to assess technology, measure our own capability and processes, and ask ourselves hard questions about where we need to focus to get the most value from our budget, (or make cuts / shift investment) if we need to.

In the squares are some examples of what you (maybe) should think about doing if you find yourself there.

Important questions to ask about VR

One of the things about Visibility and Recognition is that it’s not a given they are ‘always on’. Sometimes there are failure modes for visibility (causing a downstream issue with recognition). And sometimes there are failure modes or conditions under which you WANT to pause recognition.

The key questions you must have answers to about this include:

  • Under what conditions might I lose visibility?
  • How would I know if I have?
  • Is that loss a blind spot (i.e. data is lost for a given time period)…
  • …or is it 'a temporal delay’ (e.g. a connection fails and data is batched for moving from A to B but that doesn’t happen for a few hours)?
  • What are the recognitions that might be impacted by either of the above?
  • What is my expectation for the SLA on those recognitions from ‘cause of alert’ to ‘response workflow’?
  • Under what conditions would I be willing to pause recognition, change the workflow for what happens upon recognition, or stop it all together?
  • What is the stacked ranked list of ‘must, should, could’ for all recognition and why?

Alerts. Alerts everywhere.

More often than not, Security Operations teams suffer the costs of wasted time due to noisy alerts from certain data sources. As a consequence, it's more difficult for them to single out malicious behavior as suspicious or benign. The number of alerts that are generated due to out of the box SIEM platform configurations for sources like Web Proxies and Domain Controllers are often excessive, and the cost to tune those rules can also be unpalatable. Therefore, rather than trying to tune alerts, teams might make a call to switch them off until someone can get around to figuring out a better way. There’s no use having hypothetical recognition, but no workflow to act on what is generate (other than compliance).

This is where technologies that use ML can help. There are two basic approaches...

One is to avoid alerting until multiple conditions are met that indicate a high probability of threat activity. In this scenario, rather than alerting on the 1st, 2nd, 3rd and 4th ‘suspicious activities’, you wait until you have a critical mass of indicators, and then you generate one high fidelity alert that has a much greater weighting to be malicious. This requires both a high level of precision and accuracy in alerting, and naturally some trade off in the time that can pass before an alert for malicious activity is generated.

The other is to alert on ‘suspicious actives 1-4' and let an analyst or automated process decide if this merits further investigation. This approach sacrifices accuracy for precision, but provides rapid context on whether one, or multiple, conditions are met that push the machine(s) up the priority list in the triage queue. To solve for the lower level of accuracy, this approach can make decisions about how long to sustain alerting. For example, if a host triggers multiple anomaly detection models, rather than continue to send alerts (and risk the SOC deciding to turn them off), the technology can pause alerts after a certain threshold. If a machine has not been quarantined or taken off the network after 10 highly suspicious behaviors are flagged, there is a reasonable assumption that the analyst will have dug into these and found the activity is legitimate.

Punchline 1: the value of Continued Recognition even when 'not malicious'

The topic of paused detections was raised after a recent joint exercise between PBX Group Security and Darktrace in testing Darktrace’s recognition. After a machine being used by the PBX Red Team breached multiple high priority models on Darktrace, the technology stopped alerting on further activity. This was because the initial alerts would have been severe enough to trigger a SOC workflow. This approach is designed to solve the problem of alert overload on a machine that is behaving anomalously but is not in fact malicious. Rather than having the SOC turn off alerts for that machine (which could later be used maliciously), the alerts are paused.

One of the outcomes of the test was that the PBX Detect team advised they would still want those alerts to exist for context to see what else the machine does (i.e. to understand its pattern of life). Now, rather than pausing alerts, Darktrace is surfacing this to customers to show where a rule is being paused and create an option to continue seeing alerts for a machine that has breached multiple models.

Which leads us on to our next point…

Punchline 2: the need for Atomic Tests for detection

Both Darktrace and Photobox Security are big believers in Atomic Red Team testing, which involves ‘unit tests’ that repeatedly (or at a certain frequency) test a detection using code. Unit tests automate the work of Red Teams when they discovery control strengths (which you want to monitor continuously for uptime) or control gaps (which you want to monitor for when they are closed). You could design atomic tests to launch a series of particular attacks / threat actor actions from one machine in a chained event. Or you could launch different discreet actions from different machines, each of which has no prior context for doing bad stuff. This allows you to scale the sample size for testing what recognition you have (either through ML or more traditional SIEM alerting). Doing this also means you don't have to ask Red Teams to repeat the same tests again, allowing them to focus on different threat paths to achieve objectives.

Mitre Att&ck is an invaluable framework for this. Many vendors are now aligning to Att&ck to show what they can recognize relating to attack TTPs (Tools, Tactics and Procedures). This enables security teams to map what TTPs are relevant to them (e.g. by using threat intel about the campaigns of threat actor groups that are targeting them). Atomic Red Team tests can then be used to assure that expected detections are operational or find gaps that need closing.

If you miss detections, then you know you need to optimise the recognition you have. If you get too many recognitions outside of the atomic test conditions, you either have to accept a high false positive rate because of the nature of the network, or you can tune your detection sensitivity. The opportunities to do this with technology based on ML and anomaly detection are significant, because you can quickly see for new attack types what a unit test tells you about your current detections and that coverage you think you have is 'as expected'.

Punchline 3: collaboration for the win

Using well-structured Red Team exercises can help your organisation and your technology partners learn new things about how we can collectively find and halt evil. They can also help defenders learn more about good assumptions to build into ML models, as well as covering edge cases where alerts have 'business intelligence' value vs ‘finding bad’.

If you want to understand the categorisations of ways that your populations of machines act over time, there is no better way to do it than through anomaly detection and feeding alerts into a system that supports SOC operations as well as knowledge management (e.g. a graph database).

Working like this means that we also help get the most out of the visibility and recognition we have. Security solutions can be of huge help to Network and Operations teams for troubleshooting or answering questions about network architecture. Often, it’s just a shift in perspective that unlocks cross-functional value from investments in security tech and process. Understanding that recognition doesn’t stop with security is another great example of where technologies that let you build your own logic into recognition can make a huge difference above protecting the bottom line, to adding top line value.

INSIDE THE SOC
Darktrace cyber analysts are world-class experts in threat intelligence, threat hunting and incident response, and provide 24/7 SOC support to thousands of Darktrace customers around the globe. Inside the SOC is exclusively authored by these experts, providing analysis of cyber incidents and threat trends, based on real-world experience in the field.
AUTHOR
ABOUT ThE AUTHOR
Max Heinemeyer
Chief Product Officer

Max is a cyber security expert with over a decade of experience in the field, specializing in a wide range of areas such as Penetration Testing, Red-Teaming, SIEM and SOC consulting and hunting Advanced Persistent Threat (APT) groups. At Darktrace, Max is closely involved with Darktrace’s strategic customers & prospects. He works with the R&D team at Darktrace, shaping research into new AI innovations and their various defensive and offensive applications. Max’s insights are regularly featured in international media outlets such as the BBC, Forbes and WIRED. Max holds an MSc from the University of Duisburg-Essen and a BSc from the Cooperative State University Stuttgart in International Business Information Systems.

Book a 1-1 meeting with one of our experts
share this article
USE CASES
No items found.
PRODUCT SPOTLIGHT
No items found.
COre coverage
No items found.

More in this series

No items found.

Blog

No items found.

What you need to know about the new SEC Cybersecurity rules

Default blog imageDefault blog image
17
Jul 2024

What is new in 2023 to SEC cybersecurity rules?

Form 8-K Item 1.05: Requiring the timely disclosure of material cybersecurity incidents.

Regulation S-K item 106: requiring registrants’ annual reports on Form 10-K to address cybersecurity risk management, strategy, and governance processes.

Comparable disclosures are required for reporting foreign private issuers on Forms 6-K and 20-F respectively.

What is Form 8-K Item 1.05 SEC cybersecurity rules?

Form 8-K Item 1.05 requires the following to be reported within four business days from when an incident is determined to be “material” (1), unless extensions are granted by the SEC under certain qualifying conditions:

“If the registrant experiences a cybersecurity incident that is determined by the registrant to be material, describe the material aspects of the nature, scope, and timing of the incident, and the material impact or reasonably likely material impact on the registrant, including its financial condition and results of operations.” (2, 3)

How does the SEC define cybersecurity incident?

Cybersecurity incident defined by the SEC means an unauthorized occurrence, or a series of related unauthorized occurrences, on or conducted through a registrant’s information systems that jeopardizes the confidentiality, integrity, or availability of a registrant’s information systems or any information residing therein. (4)

How can Darktrace assist in the process of disclosing incidents to the SEC?

Accelerate reporting

Darktrace’s Cyber AI Analyst generates automated reports that synthesize discrete data points potentially indicative of cybersecurity threats, forming reports that provide an overview of the evolution and impact of a threat.

Thus, when a potential threat is identified by Darktrace, AI Analyst can quickly compile information that organizations might include in their disclosure of an occurrence they determined to be material, including the following: incident timelines, incident events, incident summary, related model breaches, investigation process (i.e., how Darktrace’s AI conducted the investigation), linked incident events, and incident details. The figure below illustrates how Darktrace compiles and presents incident information and insights in the UI.

Overview of information provided in an ‘AI Analyst Report’ that could be relevant to registrants reporting a material cybersecurity incident to the SEC
Figure 1: Overview of information provided in an ‘AI Analyst Report’ that could be relevant to registrants reporting a material cybersecurity incident to the SEC

It should be noted that Instruction 4 to the new Form 8-K Item 1.05 specifies the “registrant need not disclose specific or technical information about its planned response to the incident or its cybersecurity systems, related networks and devices, or potential system vulnerabilities in such detail as would impede the registrant’s response or remediation of the incident” (5).

As such, the incident report generated by Darktrace may provide more information, including technical details, than is needed for the 8-K disclosure. In general, users should take appropriate measures to ensure that the information they provide in SEC reports meets the requirements outlined by the relevant regulations. Darktrace cannot recommend that an incident should be reported, nor report an incident itself.

Determine if a cybersecurity incident is material

Item 1.05 requires registrants to determine for themselves whether cybersecurity incidents qualify as ‘material’. This involves considerations such as ‘the nature scope and timing of the incident, and the material impact or reasonably likely material impact on the registrant, including its financial condition and results of operations.’

While it is up to the registrant to determine, consistent with existing legal standards, the materiality of an incident, Darktrace’s solution can provide relevant information which might aid in this evaluation. Darktrace’s Threat Visualizer user interface provides a 3-D visualization of an organization’s digital environment, allowing users to assess the likely degree to which an attack may have spread throughout their digital environment. Darktrace Cyber AI Analyst identifies connections among discrete occurrences of threatening activity, which can help registrants quickly assess the ‘scope and timing of an incident'.

Furthermore, in order to establish materiality it would be useful to understand how an attack might extend across recipients and environments. In the image below, Darktrace/Email identifies how a user was impacted across different platforms. In this example, Darktrace/Email identified an attacker that deployed a dual channel social engineering attack via both email and a SaaS platform in an effort to acquire login credentials. In this case, the attacker useding a legitimate SharePoint link that only reveals itself to be malicious upon click. Once the attacker gained the credentials, it proceeded to change email rules to obfuscate its activity.

Darktrace/Email presents this information in one location, making such investigations easier for the end user.

Darktrace/Email indicating a threat across SaaS and email
Figure 2: Darktrace/Email indicating a threat across SaaS and email

What is regulation S-K item 106 of the SEC cybersecurity rules?

The new rules add Item 106 to Regulation S-K requiring registrants to disclose certain information regarding their risk management, strategy, and governance relating to cybersecurity in their annual reports on Form 10-K. The new rules add Item 16K to Form 20-F to require comparable disclosure by [foreign private issuers] in their annual reports on Form 20-F. (6)

SEC cybersecurity rules: Risk management

Specifically, with respect to risk management, Item 106(b) and Item 16K(b) require registrants to describe their processes, if any, for assessing, identifying, and managing material risks from cybersecurity threats, as well as whether any risks from cybersecurity threats, including as a result of any previous cybersecurity incidents, have materially affected or are reasonably likely to materially affect them. The new rules include a non-exclusive list of disclosure items registrants should provide based on their facts and circumstances. (6)

SEC cybersecurity rules: Governance

With respect to governance, Item 106 and Item 16K require registrants to describe the board of directors’ oversight of risks from cybersecurity threats (including identifying any board committee or subcommittee responsible for such oversight) and management’s role in assessing and managing material risks from cybersecurity threats. (6)

How can Darktrace solutions aid in disclosing their risk management, strategy, and governance related to cybersecurity?

Impact scores

Darktrace End-to-End (E2E) leverages AI to understand the complex relationships across users and devices to model possible attack paths, giving security teams a contextual understanding of risk across their digital environments beyond isolated CVEs or CVSS scores. Additionally, teams can prioritize risk management actions to increase their cyber resilience through the E2E Advisory dashboard.

Attack paths consider:

  • Potential damages: Both the potential consequences if a given device was compromised and its immediate implications on other devices.
  • Exposure: Devices' level of interactivity and accessibility. For example, how many emails does a user get via mailing lists and from what kind of sources?
  • Impact: Where a user or asset sits in terms of the IT or business hierarchy and how they communicate with each other. Darktrace can simulate a range of possible outcomes for an uncertain event.
  • Weakness: A device’s patch latency and difficulty, a composite metric that looks at attacker MITRE methods and our own scores to determine how hard each stage of compromise is to achieve.

Because the SEC cybersecurity rules require “oversight of risks from cybersecurity threats” and “management’s role in assessing and managing material risks from cybersecurity threats” (6), the scores generated by Darktrace E2E can aid end-user’s ability to identify risks facing their organization and assign responsibilities to address those risks.

E2E attack paths leverage a deep understanding of a customer’ digital environment and highlight potential attack routes that an attacker could leverage to reach critical assets or entities. Difficulty scores (see Figure 5) allow security teams to measure potential damage, exposure, and impact of an attack on a specific asset or entity.

An example of an attack path in a digital environment
Figure 3: An example of an attack path in a digital environment

Automatic executive threat reports

Darktrace’s solution automatically produces Executive Threat Reports that present a simple visual overview of model breaches (i.e., indicators of unusual and threatening behaviors) and activity in the network environment. Reports can be customized to include extra details or restricted to high level information.

These reports can be generated on a weekly, quarterly, and yearly basis, and can be documented by registrants in relation to Item 106(b) to document parts of their efforts toward assessing, identifying, and managing material risks from cybersecurity threats.

Moreover, Cyber AI Analyst incident reports (described above) can be leveraged to document key details concerning significant previous incidents identified by the Darktrace solution that the registrant determined to be ‘material’.

While the disclosures required by Item 106(c) relate to the governance processes by which the board of directors, the management, and other responsible bodies within an organization oversee risks resulting from cybersecurity threats, the information provided by Darktrace’s Executive Threat Reports and Cyber AI Analyst incident reports can also help relevant stakeholders communicate more effectively regarding the threat landscape and previous incidents.

DISCLAIMER

The material above is provided for informational purposes only. This summary does not constitute legal or compliance advice, recommendations, or guidance. Darktrace encourages you to verify the contents of this summary with your own advisors.

References

  1. Note that the rule does not set forth any specific timeline between the incident and the materiality determination, but the materiality determination should be made without unreasonable delay.
  2. https://www.sec.gov/files/form8-k.pdf
  3. https://www.sec.gov/news/press-release/2023-139
  4. https://www.ecfr.gov/current/title-17/chapter-II/part-229
  5. https://www.sec.gov/files/form8-k.pdf
  6. https://www.sec.gov/corpfin/secg-cybersecurity
Continue reading
About the author
Kendra Gonzalez Duran
Director of Technology Innovation

Blog

Inside the SOC

Hashing out TA577: Darktrace’s Detection of NTLM Hash Theft

Default blog imageDefault blog image
09
Jul 2024

What is credential theft and how does it work?

What began as a method to achieve unauthorized access to an account, often driven by the curiosity of individual attackers, credentials theft become a key tactic for malicious actors and groups, as stolen login credentials can be abused to gain unauthorized access to accounts and systems. This access can be leveraged to carry out malicious activities such as data exfiltration, fraud, espionage and malware deployment.

It is therefore no surprise that the number of dark web marketplaces selling privileged credentials has increased in recent years, making it easier for malicious actors to monetize stolen credentials [1]. This, in turn, has created new opportunities for threat actors to use increasingly sophisticated tactics such as phishing, social engineering and credential stuffing in their attacks, targeting individuals, organizations and government entities alike [1].

Credential theft example

TA577 Threat Actor

TA577 is a threat actor known to leverage stolen credentials, also known as Hive0118 [2], an initial access broker (IAB) group that was previously known for delivering malicious payloads [2]. On March 4, 2024, Proofpoint reported evidence of TA577 using a new attack chain with a different aim in mind: stealing NT LAN Manager (NTLM) hashes that can be used to authenticate to systems without needing to know plaintext passwords [3].

How does TA577 steal credentials?

Proofpoint reported that this new attack chain, which was first observed on February 26 and 27, was made up of two distinct campaigns. The first campaign consisted of a phishing attack featuring tens of thousands of emails targeting hundreds of organizations globally [3]. These phishing emails often appeared as replies to previous messages (thread hijacking) and contained zipped HTML attachments that each contained a unique file hash, customized for each recipient [3]. These attached files also contained a HTTP Meta refresh function, which triggered an automatic connection to a text file hosted on external IP addresses running as SMB servers [3].

When attempting to access the text file, the server requires an SMB session authentication via NTLM. This session is initiated when a client sends an ‘SMB_COM_NEGOTIATE’ request to the server, which answers with a ‘SMB_COM_NEGOTIATE’ response.

The client then proceeds to send a ‘SMB_COM_SESSION_SETUP_ANDX’ request to start the SMB session setup process, which includes initiating the NTLM authentication process. The server responds with an ‘SMB_COM_SESSION_SETUP_ANDX’ response, which includes an NTLM challenge message [6].

The client can then use the challenge message and its own credentials to generate a response by hashing its password using an NTLM hash algorithm. The response is sent to the server in an ‘SMB_COM_SESSION_SETUP_ANDX’ request. The server validates the response and, if the authentication is successful, the server answers with a final ‘SMB_COM_SESSION_SETUP_ANDX’ response, which completes the session setup process and allows the client to access the file listed on the server [6].

What is the goal of threat actor TA577?

As no malware delivery was detected during these sessions, researchers have suggested that the aim of TA577 was not to deliver malware, but rather to take advantage of the NTLMV2 challenge/response to steal NTLM authentication hashes [3] [4]. Hashes stolen by attackers can be exploited in pass-the-hash attacks to authenticate to a remote server or service [4]. They can also be used for offline password cracking which, if successful, could be utilized to escalate privileges or perform lateral movement through a target network [4]. Under certain circumstances, these hashes could also permit malicious actors to hijack accounts, access sensitive information and evade security products [4].

The open-source toolkit Impacket, which includes modules for password cracking [5] and which can be identified by the default NTLM server challenge “aaaaaaaaaaaaaaaa”[3], was observed during the SMB sessions. This indicates that TA577 actor aim to use stolen credentials for password cracking and pass-the-hash attacks.

TA577 has previously been associated with Black Basta ransomware infections and Qbot, and has been observed delivering various payloads including IcedID, SystemBC, SmokeLoader, Ursnif, and Cobalt Strike [2].This change in tactic to follow the current trend of credential theft may indicate that not only are TA577 actors aware of which methods are most effective in the current threat landscape, but they also have monetary and time resources needed to create new methods to bypass existing detection tools [3].  

Darktrace’s Coverage of TA577 Activity

On February 26 and 26, coinciding with the campaign activity reported by Proofpoint, Darktrace/Email™ observed a surge of inbound emails from numerous suspicious domains targeting multiple customer environments. These emails consistently included zip files with seemingly randomly generated names, containing HTLM content and links to an unusual external IP address [3].

A summary of anomaly indicators seen for a campaign email sent by TA577, as detected by Darktrace/Email.
Figure 1: A summary of anomaly indicators seen for a campaign email sent by TA577, as detected by Darktrace/Email.
Details of the name and size of the .zip file attached to a campaign email, along with the Darktrace/Email model alerts triggered by the email.
Figure 2: Details of the name and size of the .zip file attached to a campaign email, along with the Darktrace/Email model alerts triggered by the email.

The URL of these links contained an unusually named .txt file, which corresponds with Proofpoint reports of the automatic connection to a text file hosted on an external SMB server made when the attachment is opened [3].

A link to a rare external IP address seen within a campaign email, containing an unusually named .txt file.
Figure 3: A link to a rare external IP address seen within a campaign email, containing an unusually named .txt file.

Darktrace identified devices on multiple customer networks connecting to external SMB servers via the SMB protocol. It understood this activity was suspicious as the SMB protocol is typically reserved for internal connections and the endpoint in question had never previously been observed on the network.

The Event Log of a ‘Compliance / External Windows Communication’ model alert showing a connection to an external SMB server on destination port 445.
Figure 4: The Event Log of a ‘Compliance / External Windows Communication’ model alert showing a connection to an external SMB server on destination port 445.
External Sites Summary highlighting the rarity of the external SMB server.
Figure 5: External Sites Summary highlighting the rarity of the external SMB server.
External Sites Summary highlightin that the SMB server is geolocated in Moldova.
Figure 6: External Sites Summary highlightin that the SMB server is geolocated in Moldova.

During these connections, Darktrace observed multiple devices establishing an SMB session to this server via a NTLM challenge/response, representing the potential theft of the credentials used in this session. During this session, some devices also attempted to access an unusually named .txt file, further indicating that the affected devices were trying to access the .txt file hosted on external SMB servers [3].

Packet captures (PCAPs) of these sessions show the default NTLM server challenge, indicating the use of Impacket, suggesting that the captured NTLM hashes were to be used for password cracking or pass-the-hash-attacks [3]

PCAP analysis showing usage of the default NTLM server challenge associated with Impacket.
Figure 7: PCAP analysis showing usage of the default NTLM server challenge associated with Impacket.

Conclusions

Ultimately, Darktrace’s suite of products effectively detected and alerted for multiple aspects of the TA577 attack chain and NTLM hash data theft activity across its customer base. Darktrace/Email was able to uncover the inbound phishing emails that served as the initial access vector for TA577 actors, while Darktrace DETECT identified the subsequent external connections to unusual external locations and suspicious SMB sessions.

Furthermore, Darktrace’s anomaly-based approach enabled it to detect suspicious TA577 activity across the customer base on February 26 and 27, prior to Proofpoint’s report on their new attack chain. This showcases Darktrace’s ability to identify emerging threats based on the subtle deviations in a compromised device’s behavior, rather than relying on a static list of indicators of compromise (IoCs) or ‘known bads’.

This approach allows Darktrace to remain one step ahead of increasingly adaptive threat actors, providing organizations and their security teams with a robust AI-driven solution able to safeguard their networks in an ever-evolving threat landscape.

Credit to Charlotte Thompson, Cyber Analyst, Anna Gilbertson, Cyber Analyst.

References

1)    https://www.sentinelone.com/cybersecurity-101/what-is-credential-theft/

2)    https://malpedia.caad.fkie.fraunhofer.de/actor/ta577

3)    https://www.proofpoint.com/us/blog/threat-insight/ta577s-unusual-attack-chain-leads-ntlm-data-theft

4)    https://www.bleepingcomputer.com/news/security/hackers-steal-windows-ntlm-authentication-hashes-in-phishing-attacks/

5)    https://pawanjswal.medium.com/the-power-of-impacket-a-comprehensive-guide-with-examples-1288f3a4c674

6)    https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/c083583f-1a8f-4afe-a742-6ee08ffeb8cf

7)    https://www.hivepro.com/threat-advisory/ta577-targeting-windows-ntlm-hashes-in-global-campaigns/

Darktrace Model Detections

Darktrace/Email

·       Attachment / Unsolicited Archive File

·       Attachment / Unsolicited Attachment

·       Link / New Correspondent Classified Link

·       Link / New Correspondent Rare Link

·       Spoof / Internal User Similarities

Darktrace DETECT

·       Compliance / External Windows Communications

Darktrace RESPOND

·       Antigena / Network / Significant Anomaly / Antigena Breaches Over Time Block

IoCs

IoC - Type - Description

176.123.2[.]146 - IP address -Likely malicious SMB Server

89.117.2[.]33 - IP address - Likely malicious SMB Server

89.117.1[.]161 - IP address - Likely malicious SMB Server

104.129.20[.]167 - IP address - Likely malicious SMB Server

89.117.1[.]160 - IP address - Likely malicious SMB Server

85.239.33[.]149 - IP address - Likely malicious SMB Server

89.117.2[.]34 - IP address - Likely malicious SMB Server

146.19.213[.]36 - IP address - Likely malicious SMB Server

66.63.188[.]19 - IP address - Likely malicious SMB Server

103.124.104[.]76 - IP address - Likely malicious SMB Server

103.124.106[.]224 - IP address - Likely malicious SMB Server

\5aohv\9mn.txt - SMB Path and File - SMB Path and File

\hvwsuw\udrh.txt - SMB Path and File - SMB Path and File

\zkf2rj4\VmD.txt = SMB Path and File - SMB Path and File

\naams\p3aV.txt - SMB Path and File - SMB Path and File

\epxq\A.txt - SMB Path and File - SMB Path and File

\dbna\H.txt - SMB Path and File - SMB Path and File

MAGNAMSB.zip – Filename - Phishing Attachment

e751f9dddd24f7656459e1e3a13307bd03ae4e67 - SHA1 Hash - Phishing Attachment

OMNIS2C.zip  - Filename - Phishing Attachment

db982783b97555232e28d5a333525118f10942e1 - SHA1 Hash - Phishing Attachment

aaaaaaaaaaaaaaaa - NTLM Server Challenge -Impacket Default NTLM Challenge

MITRE ATT&CK Tactics, Techniques and Procedures (TTPs)

Tactic - Technique

TA0001            Initial Access

TA0002            Execution

TA0008            Lateral Movement

TA0003            Persistence

TA0005            Defense Evasion

TA0006            Credential Access

T1021.002       SMB/Windows Admin Shares

T1021  Remote Services

T1566.001       Spearfishing Attachment

T1566  Phishing

T1204.002       Malicious File

T1204  User Execution

T1021.002       SMB/Windows Admin Shares

T1574  Hijack Execution Flow

T1021  Remote Services

T1555.004       Windows Credential Manager

T1555  Credentials from Password Stores

Continue reading
About the author
Charlotte Thompson
Cyber Analyst
Our ai. Your data.

Elevate your cyber defenses with Darktrace AI

Start your free trial
Darktrace AI protecting a business from cyber threats.