Known Interactions:
UB4.C1.K3 – Use distinct browsers
UB4.C2.K1 – Click on Web Links
UB4.C2.K2 – Download Files

Protection :
UB4.C2.K1.P1 – Use a link checker
UB4.C2.K2.P1 – Validate File Extensions
UB4.C2.K2.P2 – Validate FileHashes with Threat Intelligence Sources

Threat :
UB4.C2.K1.T1 – Phishing and Fake Login Pages
UB4.C2.K2.T1 – Download Malicious Files.

KQL Query :

Identify HotSpot connections shared via IPhone
(UB2.C2.K1.T1 – WiFi managed by malicious actors)

Case :
UB2.C7 -Manage Device Logs
– UB2.C7.K1 -Clean/Remove Device Logs

Protection :
UB2.C7.K1.P1
– Restrict access to Device Logs
– Audit access to Device Logs
– Backup Device Logs

Threat :
UB2.C7.K1.T1
– Lost of non-reputation evidence
– Lack of visibility over malicious activities
– Regulatory Non-Compliance

KQL Query :
Detect Windows Security Logy removed

Months ago, I wrote an article (How non-secure ISPs Aid Attackers in Evading Detection) discussing how some malicious actors use certain Internet Service Providers (ISPs) that I categorized as risky. These ISPs fail to thoroughly investigate their customers’ activities and have weak or insufficient controls over their internet services and security measures.

Nowadays, blocking activities by country is becoming less effective due to the widespread use of VPNs and the ease of accessing global hosting services. However, Autonomous System Numbers (ASN) used for malicious activities can be impacted due to it reputation by threats detected using their service. This should be a new approach to monitor new source of potential attacks being able to monitor their associated CIDR.

Building on that article and its conclusions, I’ve come across several interesting cases that confirm certain ASNs associated with ISPs have repeatedly been reported in various online sources for involvement in malicious activities.

This post will cover the process of searching for, identifying, and responding to various ASNs identified as risky. It will also include recommendations and the corresponding KQL queries using different Defender tables:

Identifying Bad Reputation ASN

First, we can gather statistics related to hackers activities over our tenants, such as the number of emails sent tagged as threats, failed sign-in attempts, unsuccessful connection attempts, and other indicators that may signify anomalies or unexpected behaviours. Below, I’ve provided KQL queries to help identify the risky ASNs mentioned at the beggining.

You can adjust the filtering criteria by modifying the line: “| where SuspiciousPercentage > 95 and Total_different_IPs > 10” based on your specific requirements. Here are some examples you can use to gather your statistics:

Emails received detected as a Threat

//Sergio Albea
let CIDRASN = (externaldata (CIDR:string, CIDRASN:int, CIDRASNName:string)
['https://firewalliplists.gypthecat.com/lists/kusto/kusto-cidr-asn.csv.zip']
with (ignoreFirstRecord=true));
EmailEvents
| evaluate ipv4_lookup(CIDRASN, SenderIPv4, CIDR, return_unmatched=true)
| extend GeoIPData = tostring(geo_info_from_ip_address(SenderIPv4).country)
| summarize Different_IPs=make_set(SenderIPv4), Countries= make_set(GeoIPData), make_set(CIDR), make_set(SenderFromDomain), Total_different_IPs=dcount(SenderIPv4) ,Total_emails = count(),make_set(ThreatTypes),Delivered_on_Inbox= countif(DeliveryLocation has "Inbox/folder"), Email_Threat= count(isnotempty(ThreatTypes)),
Email_Valid = count( isempty(ThreatTypes)) by GeoIPData, CIDR, CIDRASNName
| extend SuspiciousRatio = Email_Threat * 1.0 / Total_emails, ValidRatio = Email_Valid * 1.0 / Total_emails
| extend SuspiciousPercentage = SuspiciousRatio * 100, ValidPercentage = ValidRatio * 100
| where SuspiciousPercentage > 95 and Total_different_IPs > 10
| order by Email_Threat
| project CIDRASNName,set_SenderFromDomain, set_CIDR, Different_IPs, Countries,Total_different_IPs, set_ThreatTypes,Total_emails, Delivered_on_Inbox, Email_Threat, Email_Valid, SuspiciousPercentage, ValidPercentage

Collecting Suspicious Sign-in attempts

//Sergio Albea
IdentityLogonEvents
| where Timestamp > ago(30d)
| summarize    Different_IPs=make_set(IPAddress), Total_different_IPs=dcount(IPAddress) ,Total_sign_attempts = count(), Suspicious_Sign_attempt = countif((ActionType has  "OldPassword") or (FailureReason has "WrongPassword") or ( FailureReason has  "validating credentials due to invalid username or password.") or ( FailureReason has "The account is locked, you've tried to sign in too many times with an incorrect user ID or password.") or (FailureReason has "Authentication failed.")   or (FailureReason has "UnknownUser") or ( FailureReason has "The user account is disabled." )),
    Success_Sign_attempt = count( ActionType has "LogonSuccess"),
    Issues_Sign_attempt = countif((FailureReason has "The session is not valid due to password expiration or recent password change.") or (  FailureReason has "General failure")) by ISP, Location
| extend    SuspiciousRatio = Suspicious_Sign_attempt * 1.0 / Total_sign_attempts,  ValidRatio = Success_Sign_attempt * 1.0 / Total_sign_attempts, IssuesRatio = Issues_Sign_attempt * 1.0 / Total_sign_attempts
| extend  SuspiciousPercentage = SuspiciousRatio * 100, ValidPercentage = ValidRatio * 100, IssuesPercentatge = IssuesRatio * 100
| where SuspiciousPercentage > 90 and Total_different_IPs > 10
| order by  SuspiciousPercentage

Once we have this information collected, we can verify the reputation of the ASN on different places such as urlhaus.abuse.ch/asn/ASNNumber/. I will show you some examples about identified ASN with high percentage of suspicious activities:

ASName: PONYNET / ASNumber: 53667

The hosting provider PONYNET is owned by a company called FranTech Solutions, which is often referred as “bulletproof host“. This term can be recognized by malicious actors as a services that tolerates or turn a blind eye to malicious activities like malware hosting, phishing, spamming, or botnet operations. This reputation attracts cybercriminals, making PONYNET a frequent target for abuse reports.

This ASN appeared multiple times in various logs, delivering email threats and initiating suspicious network activities. As a result, I reviewed its reputation:

You can use the following KQL Query to identify Device Network Events from specific ASN (as PONYNET in this example) and also check the reputation of their IPS into AbuseIPDB:

let CIDRASN = (externaldata (CIDR:string, CIDRASN:int, CIDRASNName:string)
['https://firewalliplists.gypthecat.com/lists/kusto/kusto-cidr-asn.csv.zip']
with (ignoreFirstRecord=true));
DeviceNetworkEvents
| evaluate ipv4_lookup(CIDRASN, RemoteIP, CIDR, return_unmatched=true)
| where  CIDRASN == "53667" 
| extend AbuseIPURL = strcat("https://www.abuseipdb.com/check/", RemoteIP)
| extend GeoIPData = tostring(geo_info_from_ip_address(RemoteIP).country)
| distinct  DeviceName, RemoteIP, ActionType,RemotePort,AbuseIPURL, AdditionalFields,CIDRASNName, GeoIPData, InitiatingProcessFileName, InitiatingProcessCommandLine, InitiatingProcessAccountName

ASName: Drei-K-Tech-GmbH / ASNumber: 200373

Another case is Drei-K-Tech-GmbH which is directly identified as under control of cyber-criminals by URLHaus:

Responding to detected Bad Reputation ASN

I have been building a table that consolidates various ASNs along with their associated information which will grow during the comming weeks after extensive review. This table can be used to review activities originating from the listed IPs and determine how to respond to these actions. For instance, you can leverage the actions available in Defender XDR detection rules, as outlined below:

• Emails received into Inbox Folder from Suspicious ASN/ISP

let suspicious_ISP = externaldata(CIDRASN:int, ASN_Name:string, Information:string)[@"https://raw.githubusercontent.com/Sergio-Albea-Git/Threat-Hunting-KQL-Queries/refs/heads/main/Security-Lists/suspiciousISP.csv"] with (format="csv", ignoreFirstRecord=True);
let CIDRASN = (externaldata (CIDR:string, CIDRASN:int, CIDRASNName:string)
['https://firewalliplists.gypthecat.com/lists/kusto/kusto-cidr-asn.csv.zip']
with (ignoreFirstRecord=true));
EmailEvents
| where DeliveryLocation has "Inbox/folder"
| evaluate ipv4_lookup(CIDRASN, SenderIPv4, CIDR, return_unmatched=true)
| extend GeoIPData = tostring(geo_info_from_ip_address(SenderIPv4).country)
| where isnotempty(GeoIPData)
| join kind=inner ( suspicious_ISP) on $left.CIDRASN == $right.CIDRASN
| project  Timestamp,SenderIPv4,DeliveryLocation,GeoIPData,ThreatTypes,CIDR,CIDRASN, CIDRASNName,SenderFromDomain,Subject,RecipientEmailAddress, ReportId

_{Detection Rule Action: Response : Emails : Move to mailbox folder (ex. Spam), Delete email}

• Success Sign-in attempts from Suspicious ASN/ISP

let suspicious_ISP = externaldata(CIDRASN:int, ASN_Name:string, Information:string)[@"https://raw.githubusercontent.com/Sergio-Albea-Git/Threat-Hunting-KQL-Queries/refs/heads/main/Security-Lists/suspiciousISP.csv"] with (format="csv", ignoreFirstRecord=True);
let CIDRASN = (externaldata (CIDR:string, CIDRASN:int, CIDRASNName:string)
['https://firewalliplists.gypthecat.com/lists/kusto/kusto-cidr-asn.csv.zip']
with (ignoreFirstRecord=true));
IdentityLogonEvents
| where Timestamp > ago(30d)
| evaluate ipv4_lookup(CIDRASN, IPAddress, CIDR, return_unmatched=true)
| summarize    Different_IPs=make_set(IPAddress), Total_different_IPs=dcount(IPAddress) ,Total_sign_attempts = count(), Suspicious_Sign_attempt = countif((ActionType has  "OldPassword") or (FailureReason has "WrongPassword") or ( FailureReason has  "validating credentials due to invalid username or password.") or ( FailureReason has "The account is locked, you've tried to sign in too many times with an incorrect user ID or password.") or (FailureReason has "Authentication failed.")   or (FailureReason has "UnknownUser") or ( FailureReason has "The user account is disabled." )),
    Success_Sign_attempt = count( ActionType has "LogonSuccess"),
    Issues_Sign_attempt = countif((FailureReason has "The session is not valid due to password expiration or recent password change.") or (  FailureReason has "General failure")) by ISP,CIDR,CIDRASN
| extend    SuspiciousRatio = Suspicious_Sign_attempt * 1.0 / Total_sign_attempts,  ValidRatio = Success_Sign_attempt * 1.0 / Total_sign_attempts, IssuesRatio = Issues_Sign_attempt * 1.0 / Total_sign_attempts
| extend  SuspiciousPercentage = SuspiciousRatio * 100, ValidPercentage = ValidRatio * 100, IssuesPercentatge = IssuesRatio * 100
| where SuspiciousPercentage > 90 
| join kind=inner ( suspicious_ISP) on $left.CIDRASN  == $right.CIDRASN
| order by  SuspiciousPercentage

_{Detection Rule Action: Response : User : Force Password Reset}

Conclusion

In my opinion, while we put significant effort into verifying IPs, domains, URLs, and file hashes, there’s another key player in cybersecurity protection that should take a more active role: ISPs and ASNs. Consider that there are approximately 38,802 ISPs and over 100,000 ASNs worldwide. By identifying and monitoring the risky ones, we can take a proactive approach, staying a step ahead. This would allow us to focus on monitoring these entities rather than tackling individual IPs or domains one by one.

Case :
UB2.C6 -Connect devices to charge stations via USB

Protection :
UB2.C6.P1 – Add USB condom, Use AC power outlets or External batteries

Threat :
UB2.C6.T1 Install Malware and/or steal device data via USB using Juice Jacking technique

KQL Query :
Detect Malware files attached as email using MalwareBazaar IOCs based on SHA256 File data
(UB1.C2.K1.T1 Open malicious or infected attachment files)

The Internet Service Provider (ISP) our users choose plays a critical role in safeguarding our data and assets. While many people focus on speed, reliability, and cost when selecting an ISP, one often overlooked factor is the provider’s commitment to security. The choice between a secure ISP and a ISP which not invest in security controls (which I will mention them as risky ISP) can significantly affect your data privacy, the integrity of your devices, and your overall cybersecurity posture.

Why Security in an ISP Matters

ISPs act as the gateway between your devices and the internet. They assign your IP addresses, manage data transmission, and control access to online resources. This role makes them a critical component of your network’s security. A secure ISP invests in robust security measures to monitor network traffic, protect against cyberattacks, and ensure their IPs are not exploited for malicious purposes. On the other hand, a risky ISP with lax security practices can expose its users to significant threats. Among some of the differential characteristic we can have:

• Network Monitoring : Continuous monitoring for suspicious activities VS Minimal or no monitoring of network traffic.

• IP Reputation Maintains clean and trusted IP ranges VS frequently blacklisted IPs due to malicious use.

• Data Encryption: Strong encryption for secure data transmission VS Little to no encryption, exposing sensitive data.

• Incident Response Dedicated teams for rapid threat mitigation VS slow or nonexistent response to security issues.

• Privacy Policies: Clear policies protecting user data from misuse VS data may be sold or left unprotected.

• Additional Security Features: Offers firewalls, DNS filtering, and VPN support. VS no additional tools or features for user safety.

• Cost: Slightly higher due to security investments VS often cheaper due to lack of security expenses.

• Laws and obligations: Defined and clear procedures to comply with laws and obligations (such as CERT or corresponding authorities communication) in case of malicious activities VS unclear procedures and not compliance with laws and regulations.

Classifying between secure ISPs and risky ISPs

It depends on the individual. For example, if you have the time to explore each ISP and research its capabilities and features, you can classify them based on your criteria. In my case, I use ChatGPT to gather this information, as shown in the table below:

On the other hand, you can use the following KQL Query to detect if there are users using secure or risky ISP by activities such as sign-in attempts:

//Sergio Albea
IdentityLogonEvents
| where Timestamp > ago(30d)
| summarize    Different_IPs=make_set(IPAddress), Total_different_IPs=dcount(IPAddress) ,Total_sign_attempts = count(), Suspicious_Sign_attempt = countif((ActionType has  "OldPassword") or (FailureReason has "WrongPassword") or ( FailureReason has  "validating credentials due to invalid username or password.") or ( FailureReason has "The account is locked, you've tried to sign in too many times with an incorrect user ID or password.") or (FailureReason has "Authentication failed.")   or (FailureReason has "UnknownUser") or ( FailureReason has "The user account is disabled." )),
    Success_Sign_attempt = count( ActionType has "LogonSuccess"),
    Issues_Sign_attempt = countif((FailureReason has "The session is not valid due to password expiration or recent password change.") or (  FailureReason has "General failure")) by ISP, Location
| extend    SuspiciousRatio = Suspicious_Sign_attempt * 1.0 / Total_sign_attempts,  ValidRatio = Success_Sign_attempt * 1.0 / Total_sign_attempts, IssuesRatio = Issues_Sign_attempt * 1.0 / Total_sign_attempts
| extend  SuspiciousPercentage = SuspiciousRatio * 100, ValidPercentage = ValidRatio * 100, IssuesPercentatge = IssuesRatio * 100
| order by  SuspiciousPercentage
// you can use this filter if you want to specify specific percentatge | where ValidPercentage < 10 and (SuspiciousPercentage > 90 or lockedPercentatge  > 90)

Focusing on potential risky ISPs used by malicious actors

As an attacker, I would definitely prefer to use a risky ISP instead of a secure one for the obvious reasons discussed earlier in the article about security controls. For example, using a risky ISP could means not being blocked after attack attempts and avoiding IP monitoring, among other controls.

To detect malicious activities, you need to use your threat analysis tools and logs— in my case, I rely on KQL queries for analysis.

First and foremost, it’s important to understand that malicious actors might use secure ISPs like Azure, AWS, or major national ISPs. This can result in false positives, so I employ ratios to help distinguish between legitimate and potentially malicious activities. Let’s go through the results of the KQL Query shared above:

• Case 1 : ISP using multiple different IPs trying to sign-in on my tenant, with 0 successful sign-in attempts. This provides me with useful information, such as potential IPs to be added as Indicators of Compromise (IOCs) in my Threat Intelligence platform, and allows me to monitor future activities from IPs associated with this ISP.

• Case 2: ISP using multiple different IPs to attempt sign-ins on my tenant, with some successful sign-in attempts. In addition, to the case mentioned above, it help me to identify potential accounts compromised by a Risk ISP due to the high number of attempts which could indicate, for example, a brute-force attack.

The advantage of detect Risk ISP

Once you have identified a group of risky ISPs that could affect your organization, you can gain additional security benefits. For instance, if attackers use a new IP from a risky ISP that hasn’t been seen before, instead of waiting for them to initiate an attack and be flagged as malicious by security vendors (such as VirusTotal), you can stay a step ahead by monitoring connections coming from these ISPs. This proactive approach allows you to either block connection attempts from these ISPs directly or receive immediate notifications when a connection attempt is made, depending on whether you choose to block or monitor their activities.

Secondly, if I have users who have successfully signed in from any of the identified risky ISPs, I would require them to reset their passwords or revoke access tokens due to the potentially low security standards enforced by those ISPs.

In addition, Identifying risky ISPs that have triggered multiple connection attempts—especially those that never succeeded and were classified as malicious—can provide you with valuable Indicators of Compromise (IOCs) to integrate into your Threat Intelligence platforms.

Summary

To summarise, monitoring ISPs and classifying them can help us be more proactive against attacks, reduce response time due to the known behavior of the ISP, and decrease the number of requests needed to add malicious IPs and other related indicators in our platforms.

On the other hand, I feel that sometimes we are overly focused on searching for new or trusted sources to add common indicators, such as IP addresses, URLs, domains, and file hashes. Don’t get me wrong—this is absolutely necessary. However, researching additional types of sources, like ISPs, can help us stay one step ahead and provide new indicators to protect our assets and data.

Protection:

UB3.C4.K1.P1 – Monitor activities from non-secure ISP

Threats:

UB3.C4.K1.T1 -Sign-in attempts using non-secure ISP

KQL:

Rating ISP to detect potential attacks and IOCs sources

Adding a malicious domain or sender to a safe sender list (whitelist) poses significant security risks. Users may mistakenly add these to the allowed list, believing that a legitimate email was incorrectly flagged as a threat (such as spam). However, once added, attackers can subsequently send more dangerous threats, such as malware.

In another scenario, after establishing a seemingly trustworthy communication, an attacker could request to be whitelisted to send specific documents (e.g., job applications, invoices), which may be infected. By allowing these senders to bypass email security filters, users unintentionally expose the organization to phishing attacks, malware infections, and other types of cyber threats. Below are the main threats associated with this risky behavior:

1. Bypassing Spam and Phishing Filters

Safe sender lists are designed to bypass spam and phishing filters that would normally flag or block suspicious emails. When a malicious domain or sender is whitelisted:

• Spam and Phishing Emails: Emails from the malicious sender won’t be filtered into the spam or junk folder, even if they contain harmful content. This gives attackers a direct line to the inbox.
• Increased Likelihood of Clicking Malicious Links: Since the emails come from a “trusted” sender, the recipient is more likely to interact with the email, open attachments, or click on malicious links.

2. Phishing and Credential Theft

Attackers can use phishing tactics to steal sensitive information such as login credentials, financial details, or other confidential data once they are trusted by the email system.

• Spear-Phishing Attacks: Malicious senders can craft targeted, convincing emails that appear trustworthy because they come from a whitelisted domain. These emails might request credentials, ask users to change passwords, or lead to fake login pages.
• Harvesting Corporate Information: Attackers can request confidential business information or financial details, knowing that their emails won’t be flagged as suspicious.

3. Distribution of Malware

A whitelisted malicious sender can attach files or include links that deliver malware (such as ransomware, spyware, or trojans) to the recipient’s system without being blocked by the email security gateway.

• Malicious Attachments: Since the sender is marked as safe, any attachment they send — including executable files, macros in documents, or infected PDFs — can bypass email filtering systems. Users may be more inclined to open attachments, believing they are safe.
• Links to Malware Websites: Emails containing links to malicious websites that distribute malware are more likely to be clicked if they come from a trusted sender. Once clicked, these links could install malware on the user’s device or steal sensitive information.

4. Business Email Compromise (BEC)

Business Email Compromise (BEC) occurs when attackers pose as trusted business contacts (e.g., executives, vendors, or partners) to trick users into transferring funds, providing sensitive information, or approving fraudulent requests.

• Impersonating Key Stakeholders: Once added to a safe sender list, attackers can send emails impersonating executives, finance departments, or vendors. They may request urgent wire transfers, payment of fake invoices, or access to sensitive information.
• Financial Fraud: With direct access to inboxes, attackers can engage in financial fraud, such as redirecting payments or altering invoices to ensure money is sent to fraudulent accounts.

5. Reconnaissance and Social Engineering

Once a malicious sender is whitelisted, they can send emails without being blocked, allowing them to gather more information about the organization and its employees.

• Reconnaissance: Attackers can send reconnaissance emails to gather details about your organization, such as employee names, job titles, internal processes, and projects. They can use this information to craft more convincing phishing attacks later.
• Social Engineering: They can use the data they collect from their emails to manipulate employees through social engineering tactics. For instance, they may request access to confidential documents or ask for other favors while posing as legitimate colleagues.

6. Command and Control (C2) Communication

Malware that has already infiltrated a system may require communication with a Command and Control (C2) server to receive instructions or exfiltrate data. If a malicious domain is whitelisted, any emails from these C2 servers will not be flagged, allowing for easier data theft or remote control.

• Remote Access: Attackers can use C2 servers to issue commands to infected devices, performing tasks like stealing files, installing more malware, or remotely controlling the system.
• Exfiltration of Sensitive Data: The whitelisted malicious domain could facilitate the transfer of sensitive data from your organization’s network to the attacker’s servers without detection.

7. Email Forwarding and Auto-Reply Exploits

Attackers can exploit email rules and auto-reply configurations to gain further access to sensitive information or forward internal communications to external addresses.

• Auto-Forwarding to Malicious Accounts: A whitelisted domain could request the setup of email forwarding rules, allowing attackers to receive copies of sensitive emails.
• Auto-Replies to Malicious Senders: Users may automatically respond to whitelisted senders, unknowingly providing information about their out-of-office status, travel plans, or internal processes, which can be exploited for further attacks.

8. Credential Stuffing and Account Takeover

If a malicious sender is trusted, they can engage in credential stuffing attacks by sending phishing emails with requests for login credentials or tricking the user into changing passwords on fake sites. Once they have credentials:

• Account Takeover: Hackers can gain access to email accounts, which can then be used for internal phishing, to further compromise the organization or escalate privileges.
• Lateral Movement: Once inside, attackers can move laterally within the organization to access more sensitive systems, data, or accounts.

9. Data Loss and Compliance Violations

Malicious senders could also attempt to steal sensitive information that, if compromised, could result in serious compliance violations (e.g., GDPR, HIPAA, or PCI DSS).

• Exfiltration of Sensitive Data: Attackers could gain access to confidential data (such as personal identifiable information (PII), financial records, or proprietary information) that could be sold or exposed.
• Regulatory Fines: If sensitive data is leaked or stolen, your organization could face legal and regulatory fines for failing to protect this information.

How to Mitigate These Risks:

1. Careful Review of Safe Sender Lists: Regularly audit and review the safe sender lists to ensure that no malicious domains or senders are added.
2. User Training: Educate users about the dangers of adding unfamiliar or suspicious senders to the safe list and the potential for phishing and malware.
3. Email Security Gateways: Ensure robust email security gateways are in place to scan and block malicious emails, even if the sender is mistakenly added to the whitelist.
4. Enable Multi-Factor Authentication (MFA): Enforce MFA to protect against account takeovers and credential stuffing.
5. Zero Trust Email Policies: Encourage a Zero Trust approach where users are cautious about all emails, even from whitelisted senders.
6. Monitor for Suspicious Activity: Implement monitoring tools to detect unusual activity or changes in email behavior, especially related to whitelisted domains.

Whitelisting malicious senders or domains can lead to severe consequences, so it’s important to implement strict security measures to prevent this from happening.

Configuring auto-reply messages (usually activated on vacation or absence period), while convenient, can expose users and organizations to several potential threats. Auto-reply messages can unintentionally provide too much information about the user or organization, which can be exploited by attackers.Below are some security risks and issues that can arise from improperly configured auto-reply messages:

1. Information Disclosure

• Disclosing Personal or Sensitive Information: Auto-replies may include details such as job titles, locations, project involvement, or contact information that could be used for targeted attacks.
  • Example: “I’m out of the office until October 10th. For urgent issues, contact John Doe at john.doe@company.com.”
  • Attackers can gather information about the internal structure of the company and use it in social engineeringattacks (e.g., Business Email Compromise).
• Indicating Vulnerability: If the auto-reply mentions that the user is out of the office or unavailable, it signals to an attacker that the user might not be closely monitoring emails, making them more susceptible to phishing or fraudulent activity.

2. Target for Phishing and Social Engineering

Auto-replies can serve as entry points for phishing attacks.

• Phishing Follow-Ups: Attackers can send phishing emails and then receive auto-replies that indicate that the user might not be available or may forward the message to another person. This information can help attackers customize their next attempt, making it more likely to succeed.
• Impersonation: If an auto-reply includes contact details of colleagues or managers, attackers can use that information to impersonate those individuals in spear-phishing campaigns, tricking recipients into responding to fake requests for money, credentials, or sensitive data.

3. Exposure to Spam and Malware

Auto-replies confirm that an email address is valid and active, which can make the user a target for more spam or malware-laden emails.

• Confirmation to Spammers: Auto-reply responses confirm to spammers that the email address exists and is actively monitored. This can lead to an increase in the volume of spam, including phishing emails, malicious attachments, or links to malware.
• Targeting of Out-of-Office Employees: If an attacker knows an employee is out of the office for an extended period, they might target the organization with malicious content, expecting a delayed response and taking advantage of the reduced oversight.

4. Man-in-the-Middle (MITM) Attacks

In some cases, attackers may use Man-in-the-Middle (MITM) techniques to intercept auto-reply messages.

• Gathering Metadata: By intercepting auto-reply messages, an attacker can collect information such as your email server, patterns of email flow, and organizational structure.
• Exploiting Auto-Forwards: If auto-reply or forwarding rules are configured to send messages to external email addresses (including personal or untrusted addresses), this could provide attackers with additional access points for monitoring or collecting sensitive communications.

5. Data Exfiltration

In certain environments, auto-replies might contain sensitive organizational or business information, which could be inadvertently leaked if sent to external recipients.

• Project or Contract Information: Auto-replies from employees working on sensitive projects may reveal details about contracts, partnerships, or other internal processes. An attacker could use this information to mount corporate espionage attacks.
• Vacation and Travel Plans: Details about an employee’s travel plans or vacation could help attackers target vulnerable times when key staff members are unavailable, facilitating physical security risks or planning broader attacks.

6. Malicious Email Redirection

Misconfigured auto-reply rules could be abused by attackers to reroute sensitive emails.

• Auto-Forwarding to External Accounts: If auto-reply rules are linked with forwarding messages to personal or external email addresses, an attacker who compromises a personal email account could gain access to corporate information, bypassing enterprise security measures.

7. Auto-Reply Loop (Denial of Service Risk)

If an auto-reply is sent to another email account that also has an auto-reply rule enabled (such as customer support addresses), it could create an auto-reply loop. This can result in:

• Email Flood: Both systems continuously replying to each other, flooding the inboxes with automated messages.
• Denial of Service: Excessive emails can potentially overload email systems, creating a denial-of-service scenario where legitimate emails are delayed or lost.

8. Increased Exposure to Spoofing

Auto-reply messages that indicate the user’s unavailability might embolden attackers to spoof that user’s email address while they are away.

• Impersonation: If an auto-reply message reveals that an individual is out of the office, attackers might spoof their email and send malicious messages to the user’s colleagues. These colleagues might be less suspicious since they expect the user to be unreachable.

How to Mitigate These Risks:

1. Limit Information Disclosure: Only provide essential information in auto-replies. Avoid revealing sensitive details like job titles, internal contacts, or vacation plans.
2. Use Internal-Only Auto-Replies: If possible, configure separate auto-replies for internal and external emails. External replies should be more generic and contain minimal information.
3. Avoid External Auto-Forwarding: Be cautious about configuring rules to forward emails to external addresses, especially untrusted or personal email accounts.
4. Monitor Auto-Reply Settings: Regularly review and audit auto-reply settings to ensure that they are properly configured.
5. Educate Employees: Provide security training to help employees understand the risks associated with auto-reply messages and what to avoid.

By being mindful of how auto-replies are configured and what information they include, you can reduce the risk of attacks that exploit this feature.

Case :
UB4.C2.K1 – Use plugins on websites

KQL Query :
Monitor device service tampering (UB2.C5 -Manage device services)
Detect WordPress plugins from HTTP requests (UB4.C2.K1 – Use plugins on websites. )

Case :
UB2.C6 -Connect to charge stations

KQL Query :
Detect Screenshots taken on devices (UB3.C3.T1 -Data leakage of sensitive or critical information)