March 22, 2023

Amadey Info Stealer and N-Day Vulnerabilities

Understand the implications of the Amadey info stealer on cybersecurity and how it exploits N-day vulnerabilities for data theft.

Written by

Zoe Tilsiter

Cyber Analyst

Written by

The Darktrace Threat Research Team

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.

Written by

Zoe Tilsiter

Cyber Analyst

Written by

The Darktrace Threat Research Team

Mar 2023

The continued prevalence of Malware as a Service (MaaS) across the cyber threat landscape means that even the most inexperienced of would-be malicious actors are able to carry out damaging and wide-spread cyber-attacks with relative ease. Among these commonly employed MaaS are information stealers, or info-stealers, a type of malware that infects a device and attempts to gather sensitive information before exfiltrating it to the attacker. Info-stealers typically target confidential information, such as login credentials and bank details, and attempt to lie low on a compromised device, allowing access to sensitive data for longer periods of time.

It is essential for organizations to have efficient security measures in place to defend their networks from attackers in an increasing versatile and accessible threat landscape, however incident response alone is not enough. Having an autonomous decision maker able to not only detect suspicious activity, but also take action against it in real time, is of the upmost importance to defend against significant network compromise.

Between August and December 2022, Darktrace detected the Amadey info-stealer on more than 30 customer environments, spanning various regions and industry verticals across the customer base. This shows a continual presence and overlap of info-stealer indicators of compromise (IOCs) across the cyber threat landscape, such as RacoonStealer, which we discussed last November (Part 1 and Part 2).

Background on Amadey

Amadey Bot, a malware that was first discovered in 2018, is capable of stealing sensitive information and installing additional malware by receiving commands from the attacker. Like other malware strains, it is being sold in illegal forums as MaaS starting from $500 USD [1].

Researchers at AhnLab found that Amadey is typically distributed via existing SmokeLoader loader malware campaigns. Downloading cracked versions of legitimate software causes SmokeLoader to inject malicious payload into Windows Explorer processes and proceeds to download Amadey.

The botnet has also been used for distributed denial of service (DDoS) attacks, and as a vector to install malware spam campaigns, such as LockBit 3.0 [2]. Regardless of the delivery techniques, similar patterns of activity were observed across multiple customer environments.

Amadey’s primary function is to steal information and further distribute malware. It aims to extract a variety of information from infected devices and attempts to evade the detection of security measures by reducing the volume of data exfiltration compared to that seen in other malicious instances.

Darktrace DETECT/Network™ and its built-in features, such as Wireshark Packet Captures (PCAP), identified Amadey activity on customer networks, whilst Darktrace RESPOND/Network™ autonomously intervened to halt its progress.

Attack Details

***Figure 1: Timeline of Amadey info-stealer kill chain.***

Initial Access

User engagement with malicious email attachments or cracked software results in direct execution of the SmokeLoader loader malware on a device. Once the loader has executed its payload, it is then able to download additional malware, including the Amadey info-stealer.

Unusual Outbound Connections

After initial access by the loader and download of additional malware, the Amadey info-stealer captures screenshots of network information and sends them to Amadey command and control (C2) servers via HTTP POST requests with no GET to a .php URI. An example of this can be seen in Figure 2.

***Figure 2: PCAP from an affected customer showing screenshots being sent out to the Amadey C2 server via a .jpg file.***

C2 Communications

The infected device continues to make repeated connections out to this Amadey endpoint. Amadey's C2 server will respond with instructions to download additional plugins in the form of dynamic-link libraries (DLLs), such as "/Mb1sDv3/Plugins/cred64.dll", or attempt to download secondary info-stealers such as RedLine or RaccoonStealer.

Internal Reconnaissance

The device downloads executable and DLL files, or stealer configuration files to steal additional network information from software including RealVNC and Outlook. Most compromised accounts were observed downloading additional malware following commands received from the attacker.

Data Exfiltration

The stolen information is then sent out via high volumes of HTTP connection. It makes HTTP POSTs to malicious .php URIs again, this time exfiltrating more data such as the Amadey version, device names, and any anti-malware software installed on the system.

How did the attackers bypass the rest of the security stack?

Existing N-Day vulnerabilities are leveraged to launch new attacks on customer networks and potentially bypass other tools in the security stack. Additionally, exfiltrating data via low and slow HTTP connections, rather than large file transfers to cloud storage platforms, is an effective means of evading the detection of traditional security tools which often look for large data transfers, sometimes to a specific list of identified “bad” endpoints.

Darktrace Coverage

Amadey activity was autonomously identified by DETECT and the Cyber AI Analyst. A list of DETECT models that were triggered on deployments during this kill chain can be found in the Appendices.

Various Amadey activities were detected and highlighted in DETECT model breaches and their model breach event logs. Figure 3 shows a compromised device making suspicious HTTP POST requests, causing the ‘Anomalous Connection / Posting HTTP to IP Without Hostname’ model to breach. It also downloaded an executable file (.exe) from the same IP.

***Figure 3: Amadey activity on a customer deployment captured by model breaches and event logs.***

DETECT’s built-in features also assisted with detecting the data exfiltration. Using the PCAP integration, the exfiltrated data was captured for analysis. Figure 4 shows a connection made to the Amadey endpoint, in which information about the infected device, such as system ID and computer name, were sent.

***Figure 4: PCAP downloaded from Darktrace event logs highlighting data egress to the Amadey endpoint.***

Further information about the infected system can be seen in the above PCAP. As outlined by researchers at Ahnlab and shown in Figure 5, additional system information sent includes the Amadey version (vs=), the device’s admin privilege status (ar=), and any installed anti-malware or anti-virus software installed on the infected environment (av=) [3].

***Figure 5: AhnLab’s glossary table explaining the information sent to the Amadey C2 server.***

Darktrace’s AI Analyst was also able to connect commonalities between model breaches on a device and present them as a connected incident made up of separate events. Figure 6 shows the AI Analyst incident log for a device having breached multiple models indicative of the Amadey kill chain. It displays the timeline of these events, the specific IOCs, and the associated attack tactic, in this case ‘Command and Control’.

***Figure 6: A screenshot of multiple IOCs and activity correlated together by AI Analyst.***

When enabled on customer’s deployments, RESPOND was able to take immediate action against Amadey to mitigate its impact on customer networks. RESPOND models that breached include:

Antigena / Network / Significant Anomaly / Antigena Significant Anomaly from Client Block
Antigena / Network / External Threat / Antigena Suspicious File Block
Antigena / Network / Significant Anomaly / Antigena Controlled and Model Breach

On one customer’s environment, a device made a POST request with no GET to URI ‘/p84Nls2/index.php’ and unepeureyore[.]xyz. RESPOND autonomously enforced a previously established pattern of life on the device twice for 30 minutes each and blocked all outgoing traffic from the device for 10 minutes. Enforcing a device’s pattern of life restricts it to conduct activity within the device and/or user’s expected pattern of behavior and blocks anything anomalous or unexpected, enabling normal business operations to continue. This response is intended to reduce the potential scale of attacks by disrupting the kill chain, whilst ensuring business disruption is kept to a minimum.

***Figure 7: RESPOND actions taken on a customer deployment to disrupt the Amadey kill chain.***

The Darktrace Threat Research team conducted thorough investigations into Amadey activity observed across the customer base. They were able to identify and contextualize this threat across the fleet, enriching AI insights with collaborative human analysis. Pivoting from AI insights as their primary source of information, the Threat Research team were able to provide layered analysis to confirm this campaign-like activity and assess the threat across multiple unique environments, providing a holistic assessment to customers with contextualized insights.

Conclusion

The presence of the Amadey info-stealer in multiple customer environments highlights the continuing prevalence of MaaS and info-stealers across the threat landscape. The Amadey info-stealer in particular demonstrates that by evading N-day vulnerability patches, threat actors routinely launch new attacks. These malicious actors are then able to evade detection by traditional security tools by employing low and slow data exfiltration techniques, as opposed to large file transfers.

Crucially, Darktrace’s AI insights were coupled with expert human analysis to detect, respond, and provide contextualized insights to notify customers of Amadey activity effectively. DETECT captured Amadey activity taking place on customer deployments, and where enabled, RESPOND’s autonomous technology was able to take immediate action to reduce the scale of such attacks. Finally, the Threat Research team were in place to provide enhanced analysis for affected customers to help security teams future-proof against similar attacks.

Appendices

Darktrace Model Detections

Anomalous File / EXE from Rare External Location

Device / Initial Breach Chain Compromise

Anomalous Connection / Posting HTTP to IP Without Hostname

Anomalous Connection / POST to PHP on New External Host

Anomalous Connection / Multiple HTTP POSTs to Rare Hostname

Compromise / Beaconing Activity To External Rare

Compromise / Slow Beaconing Activity To External Rare

Anomalous Connection / Multiple Failed Connections to Rare Endpoint

List of IOCs

f0ce8614cc2c3ae1fcba93bc4a8b82196e7139f7 - SHA1 - Amadey DLL File Hash

e487edceeef3a41e2a8eea1e684bcbc3b39adb97 - SHA1 - Amadey DLL File Hash

0f9006d8f09e91bbd459b8254dd945e4fbae25d9 - SHA1 - Amadey DLL File Hash

4069fdad04f5e41b36945cc871eb87a309fd3442 - SHA1 - Amadey DLL File Hash

193.106.191[.]201 - IP - Amadey C2 Endpoint

77.73.134[.]66 - IP - Amadey C2 Endpoint

78.153.144[.]60 - IP - Amadey C2 Endpoint

62.204.41[.]252 - IP - Amadey C2 Endpoint

45.153.240[.]94 - IP - Amadey C2 Endpoint

185.215.113[.]204 - IP - Amadey C2 Endpoint

85.209.135[.]11 - IP - Amadey C2 Endpoint

185.215.113[.]205 - IP - Amadey C2 Endpoint

31.41.244[.]146 - IP - Amadey C2 Endpoint

5.154.181[.]119 - IP - Amadey C2 Endpoint

45.130.151[.]191 - IP - Amadey C2 Endpoint

193.106.191[.]184 - IP - Amadey C2 Endpoint

31.41.244[.]15 - IP - Amadey C2 Endpoint

77.73.133[.]72 - IP - Amadey C2 Endpoint

89.163.249[.]231 - IP - Amadey C2 Endpoint

193.56.146[.]243 - IP - Amadey C2 Endpoint

31.41.244[.]158 - IP - Amadey C2 Endpoint

85.209.135[.]109 - IP - Amadey C2 Endpoint

77.73.134[.]45 - IP - Amadey C2 Endpoint

moscow12[.]at - Hostname - Amadey C2 Endpoint

moscow13[.]at - Hostname - Amadey C2 Endpoint

unepeureyore[.]xyz - Hostname - Amadey C2 Endpoint

/fb73jc3/index.php - URI - Amadey C2 Endpoint

/panelis/index.php - URI - Amadey C2 Endpoint

/panelis/index.php?scr=1 - URI - Amadey C2 Endpoint

/panel/index.php - URI - Amadey C2 Endpoint

/panel/index.php?scr=1 - URI - Amadey C2 Endpoint

/panel/Plugins/cred.dll - URI - Amadey C2 Endpoint

/jg94cVd30f/index.php - URI - Amadey C2 Endpoint

/jg94cVd30f/index.php?scr=1 - URI - Amadey C2 Endpoint

/o7Vsjd3a2f/index.php - URI - Amadey C2 Endpoint

/o7Vsjd3a2f/index.php?scr=1 - URI - Amadey C2 Endpoint

/o7Vsjd3a2f/Plugins/cred64.dll - URI - Amadey C2 Endpoint

/gjend7w/index.php - URI - Amadey C2 Endpoint

/hfk3vK9/index.php - URI - Amadey C2 Endpoint

/v3S1dl2/index.php - URI - Amadey C2 Endpoint

/f9v33dkSXm/index.php - URI - Amadey C2 Endpoint

/p84Nls2/index.php - URI - Amadey C2 Endpoint

/p84Nls2/Plugins/cred.dll - URI - Amadey C2 Endpoint

/nB8cWack3/index.php - URI - Amadey C2 Endpoint

/rest/index.php - URI - Amadey C2 Endpoint

/Mb1sDv3/index.php - URI - Amadey C2 Endpoint

/Mb1sDv3/index.php?scr=1 - URI - Amadey C2 Endpoint

/Mb1sDv3/Plugins/cred64.dll - URI - Amadey C2 Endpoint

/h8V2cQlbd3/index.php - URI - Amadey C2 Endpoint

/f5OknW/index.php - URI - Amadey C2 Endpoint

/rSbFldr23/index.php - URI - Amadey C2 Endpoint

/rSbFldr23/index.php?scr=1 - URI - Amadey C2 Endpoint

/jg94cVd30f/Plugins/cred64.dll - URI - Amadey C2 Endpoint

/mBsjv2swweP/Plugins/cred64.dll - URI - Amadey C2 Endpoint

/rSbFldr23/Plugins/cred64.dll - URI - Amadey C2 Endpoint

/Plugins/cred64.dll - URI - Amadey C2 Endpoint

Mitre Attack and Mapping

Collection:

T1185 - Man the Browser

Initial Access and Resource Development:

T1189 - Drive-by Compromise

T1588.001 - Malware

Persistence:

T1176 - Browser Extensions

Command and Control:

T1071 - Application Layer Protocol

T1071.001 - Web Protocols

T1090.002 - External Proxy

T1095 - Non-Application Layer Protocol

T1571 - Non-Standard Port

T1105 - Ingress Tool Transfer

References

[1] https://malpedia.caad.fkie.fraunhofer.de/details/win.amadey

[2] https://asec.ahnlab.com/en/41450/

[3] https://asec.ahnlab.com/en/36634/

The Darktrace Threat Research Team

Inside the SOC

Written by

Zoe Tilsiter

Cyber Analyst

Written by

The Darktrace Threat Research Team

Senior Product Marketing Manager, Email

Watch the NIS2 Webinar

Blog

Email

December 18, 2025

Why organizations are moving to label-free, behavioral DLP for outbound email

Why outbound email DLP needs reinventing

In 2025, the global average cost of a data breach fell slightly — but remains substantial at USD 4.44 million (IBM Cost of a Data Breach Report 2025). The headline figure hides a painful reality: many of these breaches stem not from sophisticated hacks, but from simple human error: mis-sent emails, accidental forwarding, or replying with the wrong attachment. Because outbound email is a common channel for sensitive data leaving an organization, the risk posed by everyday mistakes is enormous.

In 2025, 53% of data breaches involved customer PII, making it the most commonly compromised asset (IBM Cost of a Data Breach Report 2025). This makes “protection at the moment of send” essential. A single unintended disclosure can trigger compliance violations, regulatory scrutiny, and erosion of customer trust –consequences that are disproportionate to the marginal human errors that cause them.

Traditional DLP has long attempted to mitigate these impacts, but it relies heavily on perfect labelling and rigid pattern-matching. In reality, data loss rarely presents itself as a neat, well-structured pattern waiting to be caught – it looks like everyday communication, just slightly out of context.

How data loss actually happens

Most data loss comes from frustratingly familiar scenarios. A mistyped name in auto-complete sends sensitive data to the wrong “Alex.” A user forwards a document to a personal Gmail account “just this once.” Someone shares an attachment with a new or unknown correspondent without realizing how sensitive it is.

Traditional, content-centric DLP rarely catches these moments. Labels are missing or wrong. Regexes break the moment the data shifts formats. And static rules can’t interpret the context that actually matters – the sender-recipient relationship, the communication history, or whether this behavior is typical for the user.

It’s the everyday mistakes that hurt the most. The classic example: the Friday 5:58 p.m. mis-send, when auto-complete selects Martin, a former contractor, instead of Marta in Finance.

What traditional DLP approaches offer (and where gaps remain)

Most email DLP today follows two patterns, each useful but incomplete.

Policy- and label-centric DLP works when labels are correct — but content is often unlabeled or mislabeled, and maintaining classification adds friction. Gaps appear exactly where users move fastest
Rule and signature-based approaches catch known patterns but miss nuance: human error, new workflows, and “unknown unknowns” that don’t match a rule

The takeaway: Protection must combine content + behavior + explainability at send time, without depending on perfect labels.

Your technology primer: The three pillars that make outbound DLP effective

1) Label-free (vs. data classification)

Protects all content, not just what’s labeled. Label-free analysis removes classification overhead and closes gaps from missing or incorrect tags. By evaluating content and context at send time, it also catches misdelivery and other payload-free errors.

No labeling burden; no regex/rule maintenance
Works when tags are missing, wrong, or stale
Detects misdirected sends even when labels look right

2) Behavioral (vs. rules, signatures, threat intelligence)

Understands user behavior, not just static patterns. Behavioral analysis learns what’s normal for each person, surfacing human error and subtle exfiltration that rules can’t. It also incorporates account signals and inbound intel, extending across email and Teams.

Flags risk without predefined rules or IOCs
Catches misdelivery, unusual contacts, personal forwards, odd timing/volume
Blends identity and inbound context across channels

3) Proprietary DSLM (vs. generic LLM)

Optimized for precise, fast, explainable on-send decisions. A DSLM understands email/DLP semantics, avoids generative risks, and stays auditable and privacy-controlled, delivering intelligence reliably without slowing mail flow.

Low-latency, on-send enforcement
Non-generative for predictable, explainable outcomes
Governed model with strong privacy and auditability

The Darktrace approach to DLP

Darktrace / EMAIL – DLP stops misdelivery and sensitive data loss at send time using hold/notify/justify/release actions. It blends behavioral insight with content understanding across 35+ PII categories, protecting both labeled and unlabeled data. Every action is paired with clear explainability: AI narratives show exactly why an email was flagged, supporting analysts and helping end-users learn. Deployment aligns cleanly with existing SOC workflows through mail-flow connectors and optional Microsoft Purview label ingestion, without forcing duplicate policy-building.

Deployment is simple: Microsoft 365 routes outbound mail to Darktrace for real-time, inline decisions without regex or rule-heavy setup.

A buyer’s checklist for DLP solutions

When choosing your DLP solution, you want to be sure that it can deliver precise, explainable protection at the moment it matters – on send – without operational drag.

To finish, we’ve compiled a handy list of questions you can ask before choosing an outbound DLP solution:

Can it operate label free when tags are missing or wrong? 
Does it truly learn per user behavior (no shortcuts)? 
Is there a domain specific model behind the content understanding (not a generic LLM)? 
Does it explain decisions to both analysts and end users? 
Will it integrate with your label program and SOC workflows rather than duplicate them?

For a deep dive into Darktrace’s DLP solution, check out the full solution brief.

[related-resource]

About the author

Carlos Gray

Senior Product Marketing Manager, Email

Blog

Email

December 17, 2025

Beyond MFA: Detecting Adversary-in-the-Middle Attacks and Phishing with Darktrace

What is an Adversary-in-the-middle (AiTM) attack?

Adversary-in-the-Middle (AiTM) attacks are a sophisticated technique often paired with phishing campaigns to steal user credentials. Unlike traditional phishing, which multi-factor authentication (MFA) increasingly mitigates, AiTM attacks leverage reverse proxy servers to intercept authentication tokens and session cookies. This allows attackers to bypass MFA entirely and hijack active sessions, stealthily maintaining access without repeated logins.

This blog examines a real-world incident detected during a Darktrace customer trial, highlighting how Darktrace / EMAIL^TM and Darktrace / IDENTITY^TM identified the emerging compromise in a customer’s email and software-as-a-service (SaaS) environment, tracked its progression, and could have intervened at critical moments to contain the threat had Darktrace’s Autonomous Response capability been enabled.

What does an AiTM attack look like?

Inbound phishing email

Attacks typically begin with a phishing email, often originating from the compromised account of a known contact like a vendor or business partner. These emails will often contain malicious links or attachments leading to fake login pages designed to spoof legitimate login platforms, like Microsoft 365, designed to harvest user credentials.

Proxy-based credential theft and session hijacking

When a user clicks on a malicious link, they are redirected through an attacker-controlled proxy that impersonates legitimate services. This proxy forwards login requests to Microsoft, making the login page appear legitimate. After the user successfully completes MFA, the attacker captures credentials and session tokens, enabling full account takeover without the need for reauthentication.

Follow-on attacks

Once inside, attackers will typically establish persistence through the creation of email rules or registering OAuth applications. From there, they often act on their objectives, exfiltrating sensitive data and launching additional business email compromise (BEC) campaigns. These campaigns can include fraudulent payment requests to external contacts or internal phishing designed to compromise more accounts and enable lateral movement across the organization.

Darktrace’s detection of an AiTM attack

At the end of September 2025, Darktrace detected one such example of an AiTM attack on the network of a customer trialling Darktrace / EMAIL and Darktrace / IDENTITY.

In this instance, the first indicator of compromise observed by Darktrace was the creation of a malicious email rule on one of the customer’s Office 365 accounts, suggesting the account had likely already been compromised before Darktrace was deployed for the trial.

Darktrace / IDENTITY observed the account creating a new email rule with a randomly generated name, likely to hide its presence from the legitimate account owner. The rule marked all inbound emails as read and deleted them, while ignoring any existing mail rules on the account. This rule was likely intended to conceal any replies to malicious emails the attacker had sent from the legitimate account owner and to facilitate further phishing attempts.

Figure 1: Darktrace’s detection of the anomalous email rule creation.

Internal and external phishing

Following the creation of the email rule, Darktrace / EMAIL observed a surge of suspicious activity on the user’s account. The account sent emails with subject lines referencing payment information to over 9,000 different external recipients within just one hour. Darktrace also identified that these emails contained a link to an unusual Google Drive endpoint, embedded in the text “download order and invoice”.

Figure 2: Darkrace’s detection of an unusual surge in outbound emails containing suspicious content, shortly following the creation of a new email rule.

Figure 3: Darktrace / EMAIL’s detection of the compromised account sending over 9,000 external phishing emails, containing an unusual Google Drive link.

As Darktrace / EMAIL flagged the message with the ‘Compromise Indicators’ tag (Figure 2), it would have been held automatically if the customer had enabled default Data Loss Prevention (DLP) Action Flows in their email environment, preventing any external phishing attempts.

Figure 4: Darktrace / EMAIL’s preview of the email sent by the offending account.

Darktrace analysis revealed that, after clicking the malicious link in the email, recipients would be redirected to a convincing landing page that closely mimicked the customer’s legitimate branding, including authentic imagery and logos, where prompted to download with a PDF named “invoice”.

Figure 5: Download and login prompts presented to recipients after following the malicious email link, shown here in safe view.

After clicking the “Download” button, users would be prompted to enter their company credentials on a page that was likely a credential-harvesting tool, designed to steal corporate login details and enable further compromise of SaaS and email accounts.

Darktrace’s Response

In this case, Darktrace’s Autonomous Response was not fully enabled across the customer’s email or SaaS environments, allowing the compromise to progress, as observed by Darktrace here.

Despite this, Darktrace / EMAIL’s successful detection of the malicious Google Drive link in the internal phishing emails prompted it to suggest ‘Lock Link’, as a recommended action for the customer’s security team to manually apply. This action would have automatically placed the malicious link behind a warning or screening page blocking users from visiting it.

Figure 6: Autonomous Response suggesting locking the malicious Google Drive link sent in internal phishing emails.

Furthermore, if active in the customer’s SaaS environment, Darktrace would likely have been able to mitigate the threat even earlier, at the point of the first unusual activity: the creation of a new email rule. Mitigative actions would have included forcing the user to log out, terminating any active sessions, and disabling the account.

Conclusion

AiTM attacks represent a significant evolution in credential theft techniques, enabling attackers to bypass MFA and hijack active sessions through reverse proxy infrastructure. In the real-world case we explored, Darktrace’s AI-driven detection identified multiple stages of the attack, from anomalous email rule creation to suspicious internal email activity, demonstrating how Autonomous Response could have contained the threat before escalation.

MFA is a critical security measure, but it is no longer a silver bullet. Attackers are increasingly targeting session tokens rather than passwords, exploiting trusted SaaS environments and internal communications to remain undetected. Behavioral AI provides a vital layer of defense by spotting subtle anomalies that traditional tools often miss

Security teams must move beyond static defenses and embrace adaptive, AI-driven solutions that can detect and respond in real time. Regularly review SaaS configurations, enforce conditional access policies, and deploy technologies that understand “normal” behavior to stop attackers before they succeed.

Credit to David Ison (Cyber Analyst), Bertille Pierron (Solutions Engineer), Ryan Traill (Analyst Content Lead)

Appendices

Models

SaaS / Anomalous New Email Rule

Tactic – Technique – Sub-Technique

Phishing - T1566

Adversary-in-the-Middle - T1557

About the author

David Ison

Cyber Analyst

Your data. Our AI.

Elevate your network security with Darktrace AI

Get a demo

Check out this article by Darktrace: Amadey Info Stealer and N-Day Vulnerabilities

Amadey Info Stealer and N-Day Vulnerabilities

Background on Amadey

Attack Details

Darktrace Coverage

Conclusion

Appendices

Darktrace Model Detections

List of IOCs

Mitre Attack and Mapping

References

Beyond MFA: Detecting Adversary-in-the-Middle Attacks and Phishing with Darktrace

Why organizations are moving to label-free, behavioral DLP for outbound email

Enjoying the blog?

More in this series

React2Shell: How Opportunist Attackers Exploited CVE-2025-55182 Within Hours

Atomic Stealer: Darktrace’s Investigation of a Growing macOS Threat

CastleLoader & CastleRAT: Behind TAG150’s Modular Malware Delivery System

Blog

Email

December 18, 2025

Why organizations are moving to label-free, behavioral DLP for outbound email

Why outbound email DLP needs reinventing

How data loss actually happens

What traditional DLP approaches offer (and where gaps remain)

Your technology primer: The three pillars that make outbound DLP effective

1) Label-free (vs. data classification)

2) Behavioral (vs. rules, signatures, threat intelligence)

3) Proprietary DSLM (vs. generic LLM)

The Darktrace approach to DLP

A buyer’s checklist for DLP solutions

Blog

Email

December 17, 2025

Beyond MFA: Detecting Adversary-in-the-Middle Attacks and Phishing with Darktrace

What is an Adversary-in-the-middle (AiTM) attack?

What does an AiTM attack look like?

Inbound phishing email

Proxy-based credential theft and session hijacking

Follow-on attacks

Darktrace’s detection of an AiTM attack

Internal and external phishing

Darktrace’s Response

Conclusion

Appendices

Models