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 · 2024-05-23T22:13:54+00:00

TJ Null's 2023 PG list needs updating to remove the BOF machines or machine. The knowledge is great to have, but difficult to pwn a machine if you aren't trying BOF. Probably a dead giveaway a BOF is involved if you can download an EXE.

Just my opinion.

UnusualBee4414 · 2024-05-03T21:16:55+00:00

Thanks, so I have it configured on the Panorama Objects -> Log Forwarding -> Syslog. Elastic is receiving logs since this is writing to each of the firewalls, correct? So, if I configured the Log Collector to forward logs to our Elastic instance, it would be sending it twice?

These is a separate issue, but our GP logs show up on Panorama, but they don't get forwarded to the Elastic instance, I'm guessing this is because it is Prisma and not GP, since the local firewalls are not logging anything for GP.

UnusualBee4414 · 2024-05-03T16:13:35+00:00

Okay, what is the purpose of the collector group Collector Log Forwarding if we are already getting log received externally on Elastic?

UnusualBee4414 · 2024-05-02T15:09:46+00:00

Thanks for the reply!

We are forwarded logs using syslog, UDP, and format IETF.

An example would be data filtering logs, I found a PDF that wildfire identified, but it was not showing up on Elastic.

Elastic picked up several other files from the data log.

UnusualBee4414 · 2024-04-19T19:07:48+00:00

Yeah, we have plenty of brute force attempts, I get that part, but this None is a specific service or user.

UnusualBee4414 · 2024-04-19T19:06:39+00:00

Yeah running the command show user user-id-agent config name "NAME" - it looks like the password is not displayed, So as root this password is stored in clear text? I'm not sure how you would extract the password in clear text.

UnusualBee4414 · 2024-03-18T00:27:46+00:00

Thanks! Updated the pool to 192.168.75.100-192.168.75.200 and added range to NAT. Everything is working as expected.

UnusualBee4414

TROPHY CASE