brute for attack detected by defender in pgsql

Question

brute for attack detected by defender in pgsql

prasantc 996

Brute force attack showing microsoft ipv6 address as source form azure fd40:891 hitting multiple time to azure psql. How to find this source IPV6 system. Is it from MS services or private endpoint? Is there are way to search for IPV6 source

prasantc 996 Reputation points

2026-04-24T01:49:45.7033333+00:00

how to find where is the ip address and device name
prasantc 996 Reputation points

2026-04-24T01:50:23.7333333+00:00

how to find where in microsoft azurre this IP address belongs to
SAI JAGADEESH KUDIPUDI 2,625 Reputation points Microsoft External Staff Moderator

2026-04-24T09:14:02.6633333+00:00
Hi prasantc,

Thanks for your detailed question — I completely understand that you want to identify which Azure resource or device is associated with the IPv6 address and whether it’s coming from Microsoft services or your internal setup.
What this IPv6 address indicates

The IPv6 address you’re seeing (for example fd40:…) is part of a private address space, which typically means the traffic is coming from within your Azure virtual network rather than from the public internet.

In Azure Database for PostgreSQL, this usually happens when:

You are using Private Endpoint / Private Link, or

A resource inside your VNet is connecting to the database

With Private Link, Azure assigns a private IP via a network interface (NIC) inside your VNet, and all traffic flows securely over the Microsoft backbone instead of the internet.
About the Defender alert
The alert you’re seeing is expected behavior from Microsoft Defender for Cloud.

Defender detects patterns like repeated failed logins (brute-force attempts) and raises alerts to help you investigate potential risks.

These alerts can be triggered even if the source IP is internal or from Azure infrastructure — because detection is based on behavior, not IP ownership.

How to find which resource this IP belongs to

There isn’t a direct “IP → device name” lookup in Azure for private IPs. However, you can reliably identify the source using the following approach:

Map the IP to a Network Interface (NIC)

In Azure, every private IP is assigned to a network interface attached to a resource (VM, Private Endpoint, etc.).

You can list NICs and check their IP configurations using Azure CLI:
Once you find the NIC:

You’ll see the attached resource (VM / Private Endpoint)

That gives you the **actual origin of the traffic

Check Private Endpoint configuration

If your PostgreSQL server uses Private Endpoint:

Go to PostgreSQL → Networking → Private Endpoint

Open the associated Network Interface (NIC)

A private endpoint is implemented as a NIC with a private IP in your VNet.
3. Review Defender alert details

Go to:

Azure Portal → Defender for Cloud → Security Alerts

Each alert includes:

Affected resource

Activity details

Suspicious login pattern

This often helps pinpoint:

Which application/user is generating the traffic

Use network logs for confirmation

If needed, enable VNet Flow Logs / NSG Flow Logs:

Logs show source IP, destination, and traffic flow

Useful for identifying “who is talking to the database”
Likely cause (based on patterns)

In most cases like this, the root cause is:

A misconfigured application

Incorrect credentials stored in an app/service

Retry logic causing repeated login attempts
Recommended next steps

Identify the NIC associated with the IP

Check Private Endpoint and VNet resources

Review PostgreSQL logs for failed logins

Fix any application using incorrect credentials

Restrict access if needed (avoid overly broad rules)

The IPv6 address most likely belongs to an **internal Azure resource (not external attacker)**Azure does not provide a direct IP-to-device mapping
You can identify the source by tracing it through: NIC → Resource → Application

Microsoft Reference Links:
Azure Database for PostgreSQL networking with Private Link
Overview of Microsoft Defender for Open-Source Relational Databases
Alerts for open-source relational databases
az network nic
Add private endpoint connections
Security alerts overview
Virtual network flow logs overview

Hope this helps. If you have any follow-up questions, please let me know. I would be happy to help.
Please do not forget to "Accept Answer" and "up-vote" wherever the information provided helps you, as this can be beneficial to other community members.
SAI JAGADEESH KUDIPUDI 2,625 Reputation points Microsoft External Staff Moderator

2026-05-03T09:35:41.0033333+00:00

Hi prasantc,
I hope you had a chance to review the information shared earlier, and I hope this information has been helpful! If you still have questions, please let us know what is needed in the comments so the question can be answered.

1 answer

Your answer

prasantc 996 Reputation points

2026-04-24T01:49:45.7033333+00:00

how to find where is the ip address and device name
prasantc 996 Reputation points

2026-04-24T01:50:23.7333333+00:00

how to find where in microsoft azurre this IP address belongs to
SAI JAGADEESH KUDIPUDI 2,625 Reputation points Microsoft External Staff Moderator

2026-05-03T09:35:41.0033333+00:00

Hi prasantc,
I hope you had a chance to review the information shared earlier, and I hope this information has been helpful! If you still have questions, please let us know what is needed in the comments so the question can be answered.

Answer 1

Microsoft Defender for Cloud for Azure Database for PostgreSQL detects and alerts on brute force patterns, including those originating from Microsoft-owned IP ranges.

When repeated failed logins or credential guessing attempts are detected against Azure Database for PostgreSQL, Defender raises alerts such as:

Suspected brute force attack
Suspected brute force attack using a valid user
Suspected successful brute force attack

These alerts can appear even if the source IP is a Microsoft/Azure address (including IPv6) because Defender analyzes behavior, not ownership of the IP. A Microsoft or Azure IP can still be the origin of:

Legitimate but misconfigured or noisy clients (for example, an app or service repeatedly retrying with bad credentials), or
Malicious/unauthorized traffic traversing Azure infrastructure.

Recommended actions based on the provided context:

Review the Defender alert details
- In the Azure portal, open Microsoft Defender for Cloud → Security alerts and locate the PostgreSQL brute force alert.
- Open the specific alert to see details such as database name, server name, application name, event time, and recommended actions.
Verify whether the traffic is expected
- Check if any Azure services, applications, or automation in the environment use that IPv6 address or subnet to connect to the PostgreSQL server.
- If the source is a known application, review its connection string and credentials to ensure they are correct and not causing repeated failed logins.
Harden network access
- Configure network controls so only required clients can reach the PostgreSQL server:
  - Use private endpoints for Azure Database for PostgreSQL so traffic does not traverse the public internet.
  - Disable broad rules such as “Allow access to Azure services” to avoid accepting connections from any Azure subscription.
Enforce secure connections
- Ensure require_secure_transport is set to on so all connections use SSL/TLS, reducing risk of credential interception.
Enable logging and threat detection best practices
- Enable diagnostic logging and audit logging (for example, via pgaudit) to capture detailed login attempts and correlate them with Defender alerts.
- Use Microsoft Defender for Open-Source Relational Databases to continue receiving advanced threat protection and recommendations.
Respond to alerts systematically
- Use the Defender for Cloud security alerts page to monitor all active threats.
- Follow the recommended actions in each alert to investigate and mitigate, and, if needed, continue investigations with tools like Microsoft Sentinel.

If the IPv6 address is not recognized as part of the environment and continues to generate brute force alerts, tighten firewall rules and network access so only explicitly allowed IPs or private endpoints can connect.

References:

Share via

brute for attack detected by defender in pgsql

1 answer

Your answer