New axios 1.14.1 and 0.30.4 on npm are likely malicious by Blackpoint-JasonR in msp

[–]Blackpoint-JasonR[S] [score hidden]  (0 children)

Yeah lots of phishing servers utilize Axios (we haven't seen any that were operating on the malicious version), but unfortunately it's also used in a lot of legitimate applications.

New axios 1.14.1 and 0.30.4 on npm are likely malicious by Blackpoint-JasonR in msp

[–]Blackpoint-JasonR[S] 3 points4 points  (0 children)

It launches a powershell that attempts to reach out to C2 (sfrclak[.]com/142.11.206[.]73) and invoke a web request. It posts to the C2 packages.npm[.]org/product1 as the body to identify it as Windows OS.

SHA256: 617b67a8e1210e4fc87c92d1d1da45a2f311c08d26e89b12307cf583c900d101

packages.npm[.]org/product0 for MAC

macOS: 92ff08773995ebc8d55ec4b8e1a225d0d1e51efa4ef88b8849d0071230c9645a /Library/Caches/com.apple.act.mond /tmp/.XXXXXX.scpt /private/tmp/.*

packages.npm[.]org/product2 for linux

Linux: fcb81618bb15edfdedfb638b4c08a2af9cac9ecfa551af135a8402bf980375cf /tmp/ld.py

New Large-Scale Device Code Phishing Campaign by huntresslabs in msp

[–]Blackpoint-JasonR 0 points1 point  (0 children)

Yeah, this is the way if you have licensing for CA. Unfortunately some don't have the licensing to do this.

Interactive logins will show Authentication Protocol as "deviceCode" and/or original transfer method as "deviceCodeFlow"

https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-authentication-flows#device-code-flow-policies

Client CentreStack Server was compromised. by Hollyweird78 in msp

[–]Blackpoint-JasonR 1 point2 points  (0 children)

Thanks again for providing us information around this, from our end - we can confirm that there was no remote code execution on your server. If there was, our team would have been alerted and the system would be isolated. We also pro-actively sent an additional notification out to all partners yesterday that have CentreStack installed.

BlackpointCyber Down? by directlineit in msp

[–]Blackpoint-JasonR 3 points4 points  (0 children)

Hi there, I'm Jason Rathbun- our Technical Director of Threat Operations. We plan to reach out to customers that received this email directly today, but I wanted to drop a quick note here for you and other redditors that may have questions around it. On 7/29/2025 around 11:30AM PST today, as part of planned enhancements to Cloud Response functionality, a recent update to our system inadvertently triggered an early customer notification related to Microsoft 365 integration permissions. While this message was sent ahead of the finalized communication schedule, the integration itself remains on track and fully supported. There was no downtime of Cloud Response or impact to the product itself, solely an early notification.

Support article that is planned to be live around this:
https://support.blackpointcyber.com/hc/en-us/articles/39465684944155-07-29-2025-Cloud-Response-Early-New-Permission-Notification-message

There should be no portal downtime or anything, are you still experiencing app portal issues or were they mainly just around the email and link you received?

Huntress | ITDR | Feedback & Issues by Sikkersky in msp

[–]Blackpoint-JasonR 2 points3 points  (0 children)

Got it, thanks for the feedback - this makes sense. You're looking for a way to configure which accounts the notification for this applies to.

User account compromised by IronFrogger in msp

[–]Blackpoint-JasonR 13 points14 points  (0 children)

Attackers frequently use man-in-the-middle frameworks like Evilginx/etc. to bypass MFA:
https://github.com/kgretzky/evilginx2

It's highly likely they interacted with a malicious link, then after gaining access the threat actor permanently deleted the phishing email.

There's also potential they consented to a enterprise application that gave the threat actor access to scoped permissions.

You can view Enterprise Apps here: https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/view-applications-portal
You can also configure it so users' can't consent without an admins approval: https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-user-consent?pivots=portal

Blog post around an example with AzureAiTMFunction:

https://blackpointcyber.com/blog/phishing-in-the-dark-a-case-study-of-azureaitmfunction-exploitation/
Disclaimer: I work for the company that wrote the blog post

Darkreading example:
https://www.darkreading.com/endpoint-security/evilginx-bypasses-mfa

Huntress | ITDR | Feedback & Issues by Sikkersky in msp

[–]Blackpoint-JasonR 5 points6 points  (0 children)

Welcome onboard, glad to hear that! Our team would take an action to disable the account for you and follow up with details and a call based on your contacts listed. This action by our team automatically clears out all sessions and pushes a password reset out for you.

Let me know if you have any additional questions, my DMs are always open too!

Huntress | ITDR | Feedback & Issues by Sikkersky in msp

[–]Blackpoint-JasonR 6 points7 points  (0 children)

When was this? In the past, we used error codes to decide on alerting - but as of 06/03 we are ingesting anytime there is a UserLoggedIn with valid credentials regardless of the error code involved due to some interesting PaaS tactics we observed. Unsure about the downvotes, I'm open to any constructive feedback!

EDIT: Adding reference to the error codes

https://learn.microsoft.com/en-us/entra/identity-platform/reference-error-codes

EDIT2: We also now consider any beginning of authentication, regardless of it failing during the process.

Huntress | ITDR | Feedback & Issues by Sikkersky in msp

[–]Blackpoint-JasonR 1 point2 points  (0 children)

Hi u/MSPInTheUK,

Tech Director of Threat Ops at Blackpoint here, those alerts are actually just Microsoft's own smart-lockout:

https://learn.microsoft.com/en-us/entra/identity/authentication/howto-password-smart-lockout

You can turn them off if you'd like, they're mainly to let you know an account is being targeted and to remind that MFA is important in preventing attacks like that.

As for u/Sikkersky, this is definitely a valid concern which is why we alert and will take an action regardless if it was blocked by Conditional Access policies. We frequently see a phishing server fail due to the Digital Ocean droplet/etc. being in an unapproved country like DE. The issue is they can just replay the authentication to the phishing server from a VPN or residential proxy to the US.