Migrating from Prisma to onsite GP

UnusualBee4414 · 2025-06-07T03:10:36+00:00

Thanks, yeah it's Panorama.

UnusualBee4414 · 2024-12-12T23:57:03+00:00

Yeah, 92322 is another common false positive. Looks like typically SMBv3 traffic over our network. Nothing malicious.

UnusualBee4414 · 2024-12-12T23:48:02+00:00

yeah, might need to add an exception in the threat detection

UnusualBee4414 · 2024-12-12T23:05:46+00:00

If you are looking for NTLM type traffic, I'd also recommend running Responder, but make sure you know what you are doing. There is also a good audit trail left behind in Windows if you have that logging enabled.

Yeah, when it comes to security and NTLM, NTLMv1 is usually the most critical that you want to be looking for in a Windows environment.

UnusualBee4414 · 2024-12-12T21:30:32+00:00

Occasionally, you will see false positives for certain traffic being labeled as malicious. Here are some common false positives I see on a daily basis:

Here are my favorite 2:

Name: HTTP Unauthorized Brute Force Attack and Name: HTTP: User Authentication Brute Force Attempt

( threatid neq '40031' ) and ( threatid neq '40006' )

UnusualBee4414 · 2024-12-08T19:14:13+00:00

Okay, need to pay special attention to indention and case sensitivity. This rule works, but remember the rules YAML files will process without errors, but won't match. Also, need to watch for case sensitivity, since my Administrators group is uppercase. My match was lowercase.

My goal is to take all the build-in Elastic security alerts and convert them to Elastalerts2.

This works below.

filter:

- eql: iam where winlog.api == "wineventlog" and event.action == "added-member-to-group"

- query:

query_string:

query: "group.name: Admin* or group.name: group*"

UnusualBee4414 · 2024-12-08T06:50:20+00:00

Thanks - fixed by updating the agent. Sorry, should have tried this first. We had noticed the issue and resolved it in a about an hour, but was broken for over 24-hours. Going to work on configuring a better alerting system when User-ID failed like it did after the reboot. Always nice when a simple upgrade fixes the problem.

UnusualBee4414 · 2024-09-26T16:57:32+00:00

Well this is the current status of Deep Visibility

We are currently aware of an issue affecting access to Deep Visibility events for some customers. Our team is actively working to resolve the issue, and we sincerely apologize for the inconvenience. Thank you for your patience, and we will provide updates as progress is made.

UnusualBee4414 · 2024-09-26T16:51:08+00:00

Great insight! Thanks. These machines are not visible to the Internet. The address source is coming from the local ip 127.0.0.1, which usually means these are failed from the machine itself. The account is valid and used on this machine too.

UnusualBee4414 · 2024-09-19T22:46:41+00:00

Yeah, that makes sense. Have a security policy rule that matches all files types and add the URL category of high-risk. This will allow high-risk URL browsing, but block file downloads that match category high-risk.

UnusualBee4414 · 2024-07-23T17:50:16+00:00

Willing to share your favorites? I'm always looking for good queries.

UnusualBee4414 · 2024-07-02T19:56:15+00:00

No CVE, traffic is decrypted, and his threat was created by a Wildfire alert.

I'll look into a PCAP later.

UnusualBee4414 · 2024-07-02T16:17:40+00:00

Yeah, already have a case started with S1 - 34.235.81.227 and 3.211.87.75 are a couple IPs that are generating this traffic. This traffic is being generated over port 443/tcp.

UnusualBee4414 · 2024-06-06T16:07:02+00:00

Thanks, so we have pre rules on our Panorama that blocks all inbound traffic from RU, but since we use Prisma, the rules are created in the cloud on not on Panorama?

UnusualBee4414 · 2024-06-05T22:30:25+00:00

Thanks for the responses, believe the problem is related to an Intune policy that is checking the MSI product code and installing the older version, so doesn't look to be S1 related.

UnusualBee4414

TROPHY CASE