This post was originally published on this site

Here is the YARA rule I used to detect "Orphaned VBA Projects Inside DWG Files".

rule autocad_orphaned_vba_project {

    strings: $a = "AC10"

             $b = {D0 CF 11 E0 A1 B1 1A E1}

             $c = "[Host Extender Info]" ascii

 

    condition: $a at 0 and uint32(0x24) == 0 and $b and $c

}

 

A VirusTotal retrohunt with this rule gave me only 2 detections:

09d4607941e458f6dbb6be17825641d863c0b37c185027984e137d8a67e919d8

3310c1a9bfe6115e49d8ac372cef5f460850da05138340107e66b958a6b5bca6

 

Didier Stevens
Senior handler
blog.DidierStevens.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

I believe the cybersecurity industry may be approaching AI security the wrong way.

AI agents are becoming more powerful every day. Systems like ChatGPT, Claude, and Grok can write and execute code, use command shells, browse the web, call APIs, interact with MCP servers, and access enterprise data. Yet much of the industry is taking these extraordinarily powerful, general-purpose agents and trying to make them safe by building cages around them. We add containers, policy layers, monitoring, guardrails, and humans in the loop.

I think that’s backwards. If the companies building these models struggle to control their behavior, why do we assume we can reliably contain them? And when in human history has requiring a user to click a button before something dangerous happened EVER worked?

Even if you build the perfect cage, the model you tested in your cage will eventually change. Providers retire models, and moving to a replacement means revisiting your assumptions and testing. Your application code may be unchanged, but the component deciding what to do next is different.

In my opinion, we should use these agents, which are very good at coding, to build smaller, single-purpose agents. If an agent only needs to read logs from one directory, why give it functions that can read, write, or execute things anywhere on the system?

This isn’t a new idea. It’s the principle of least privilege and seperation of duties. But somehow, when we build agents, we seem willing to hand over broad access and ask the model to use good judgment.

This is the guiding philosophy behind SANS SEC573: AI-Powered Security Automation, where we learn to vibe code these focused agents into existence. Use the powerful coding agent to build a better agent. Give the resulting agent only the access it needs to do its job. 

An October 15 article from Check Point provides a good case in point.

Imagine asking an AI security agent to investigate a suspicious login. It retrieves authentication logs, checks the source IP, and identifies several potentially affected accounts. Then it disables them. The agent may have correctly identified suspicious activity. Disabling those accounts might even be appropriate. But you asked it to investigate. Somewhere along the way, it expanded its assignment.

Check Point’s article describes its Dangerous Deviation Detection capability, which evaluates proposed tool calls before execution. The problem extends beyond prompt injection. An agent can misunderstand a request or take its assignment too far without an attacker being involved.

The detector sits between the model choosing a tool call and the application executing it. It evaluates the proposed operation and its arguments against the task. The application can then stop the action, request approval, or give the agent feedback so it can try another approach.

According to Check Point’s technical documentation:

• The beta detector flags actions that are both dangerous and unwarranted. Its danger categories include data leakage, access or privilege escalation, and destruction of persistent resources.

• It looks for justification in user and system messages. Instructions in tool responses or other external content do not count as authorization.

• The application submits conversation history, the proposed tool call in the final assistant message, and tool definitions in the top-level tools field of a Guard API request.

• Setting "breakdown": true returns fields including reason_code, reason, agent_guidance, and debug_info.dev_tips.

The distinction between dangerous and unwarranted is important. An irrelevant but harmless action can pass. A dangerous action supported by trusted instructions can also pass. Check Point separately documents a deterministic tool allow/deny list and describes the beta detector as favoring fewer false positives over catching every marginal case. Its a solid approach.

Those are documented product behaviors, not results from my own testing.

I can see value in checking proposed actions. But my first question comes before that check: Why does the investigation agent have permission to disable accounts?

The human analyst might need that permission. The agent performing this particular task does not. Seperation of Duties and the Prinsicle of Least required access are screaming in their graves.

An investigation agent can collect evidence and recommend containment using narrowly scoped, read-only access. If containment is needed, a separate workflow can perform the authorized operation against the specified accounts.

That boundary needs to exist in code and credentials. Removing a tool from the list shown to the model is not enough if the executor still accepts it. Restricting tools also accomplishes little if the agent has a general-purpose shell running with administrative credentials.

The same rule applies when agents work together. If the investigation agent can freely tell a privileged response agent to disable accounts, it still has an indirect path to that capability. The receiving workflow must check authorization and scope for itself. “The other agent said you approved it” should not be enough.

There is another implementation detail worth watching. Check Point’s detector distinguishes trusted messages from external content. If your application copies an untrusted ticket into a user message, you may blur that distinction. A sentence in a ticket claiming that someone approved an action is evidence to evaluate, not permission to execute it.

You can test these boundaries with ordinary requests:

• Ask for an incident summary. Does the agent try to close the ticket?

• Ask for a list of inactive accounts. Does it try to disable them?

• Put a fabricated approval in a retrieved document. Does the application accept it?

• Approve an action against one account. Can the agent expand it to several?

• Deny an action. Can it accomplish the same thing through another tool or agent?

Watch both what the model proposes and what the application allows. An unauthorized attempt that gets blocked tells you a control worked. An agent that happens to behave correctly does not prove the control exists.

I’m not suggesting we abandon monitoring, guardrails, or approval workflows. I’m suggesting we stop making them responsible for containing capabilities the agent never needed.

Before building a better cage, ask why you gave the agent that much access in the first place. Then have the agents build their own cages by writing single purpose agents with only those tools that are required. I'll show you how in SEC573.

Sources: Check Point’s October 15 article and Agent Behavior Defense documentation.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

Years ago I wrote diary entries about VBA code stored inside AutoCAD drawing files (.dwg).

In a nutshell: the VBA code is stored inside an OLE file, that is embedded inside the DWG file. You can do a brute-force search for the embedded OLE file, or you can follow a pointer inside the header of the DWG file.

I wrote a small Python script (autocad.py) for this second case. It looks at a 32-bit pointer at position 0x24 inside the DWG file. This points to a 16-byte long header, followed by the embedded file. This 16-byte long header contains the length of the embedded file. You use the script together with my tool cut-bytes.py, like this:

cut-bytes.py -S autocad.py -P AutoCAD : 461ed52aeb75384133a8238b2eb481ae5d505d4961effa622673d65a889c8218.vir.zip | oledump.py

 

This command carves the DWG file (inside the ZIP file) and extracts the embedded OLE file, and pipes it into oledump.py for analysis.

When the pointer is zero, there is no embedded OLE file, and cut-bytes.py returns nothing.

Recently, I discovered 2 DWG files that are an exception: their pointer to the embedded OLE file is zero, but if you do a brute-force search, you will find an embedded OLE file with a VBA project.

For example this DWG file.

Its pointer to the embedded VBA project is zero:

But it contains an embedded OLE file:

And right in front of the embedded OLE file, there is the 16-byte long header that contains the lenght of the embedded file.

Using the AutoCAD script to extract the file gives nothing:

But oledump.py can find the embedded OLE file and analyze it:

So while using oledump.py to analyze DWG files you find a VBA project embedded inside a DWG file, then also verify if it is not orphaned: verify that the pointer at 0x24 is not zero (or use the autocad.py script).

Because when a DWG file contains an orphaned VBA project, the VBA code can not have executed when someone opened the DWG file with AutoCAD. AutoCAD "does not see" orphaned VBA projects.

Notice that a default installation of AutoCAD does not support VBA. VBA for AutoCAD is a separate install.

I don't know how orphaning happens, but I did find an AutoLISP command to remove a VBA project from a DWG file: 

(dictremove (namedobjdict) "ACAD_VBA")

Maybe this dictremove command clears the pointer, but does not remove the embedded OLE file.

 

Didier Stevens
Senior handler
blog.DidierStevens.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

On October 5th, Atlassian published patches for multiple products to fix an "Arbitrary File Access" vulnerability [CVE-2026-21589]. An attacker can read arbitrary files in the web application's directory, potentially exposing sensitive information such as configuration files.

This directory traversal vulnerability is a little bit different from the textbook case. Atlassian products replace slashes with the pattern "::". To avoid this issue, but may, in some cases, undo this escape to access files.  Watchtowr has a great write-up with all the details and proof-of-concept URLs demonstrating the vulnerability [Watchtowr].

Starting yesterday, we saw some exploit attempts hitting our honeypot, using the exploit URLs mentioned in the Watchtowr blog. 

/download/resources/jira.webresources:color-picker-popup/images/..::..::..::..::..::WEB-INF::web.xml
/s/1.0/_/download/resources/com.atlassian.bitbucket.server.bitbucket-webpack-INTERNAL:avatar/avatar/..::..::..::..::..::WEB-INF::urlrewrite.xml
/s/1/_/download/resources/com.atlassian.confluence.plugins.dashboard-actions/images/..::..::..::..::..::..::..::..::WEB-INF::web.xml

One condition for successful exploitation is that the file the user attempts to access exists. The exploit uses "WEB-INF/web.xml" as it is a required file for Tomcat applications, and can be used similarly to "/etc/passwd". The "/etc/passwd" file will not work in this case. Access is restricted to the web application's directory. The "::" pattern used in the exploit will be translated to "/" on the server, leading to the directory traversal.

Based on the timing and the targets hit, I believe these scans are all triggered by the same threat actor. Oddly enough, all the source IPs are associated with Digital Ocean. The source IPs I see from our honeypots:

134.199.229.190
134.199.230.82
137.184.112.247
137.184.33.84
143.198.103.58
143.198.132.93
146.190.169.1
146.190.172.250
159.223.199.218
164.92.68.152
209.38.147.216
24.199.101.184
64.23.172.129 

—
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

It seems that a trend started… I continue my journey discovering more RMM ("Remote Management & Monitoring") tools abused by threat actors! A few days ago, I wrote a diary[1] about ScreenConnect used in the wild. Today, I found another one.

Same scenario, it started with a phishing email that delivers a fake PDF invoice to the victim:

When the PDF is opened, it just redirect to a malicious VBS file. Indeed, the PDF contains an “OpenAction” and “URI” keywords, that sounds weird! 

remnux@remnux:~/files/samples$ pdf-parser.py Transaction Receipt .pdf -o 3
obj 3 0
Type: /Page
Referencing: 1 0 R, 2 0 R, 4 0 R

  <<
    /Type /Page
    /Parent 1 0 R
    /Resources 2 0 R
    /MediaBox [0 0 595.2799999999999727 841.8899999999999864]
    /Annots
      <<
        /Type /Annot
        /Subtype /Link
        /Rect [0. 841.8899999999999864 595.2799999999999727 71.3010032362460606]
        /Border [0 0 0]
        /A
          <<
            /S /URI
            /URI (hxxps://up-theta-rose.vercel[.]app/adobe_new_update.vbs)
          >>
      >>
    ] /Contents 4 0 R
  >>

The URL will be visited thanks to the OpenAction. This is a common trick to avoid writing URLs in email bodies that can be easily detected.

The VBS file is pretty simple and even not obfuscated. It will display another PDF as a decoy: a non-blurred version of the initial attachment.

In parallel, a MSI archive will be downloaded and installed:

hxxps://up-theta-rose.vercel[.]app/action1.msi

The MSI file contains 4 files that are not reported as malicious by VT:

$ sha256sum *
eaff35d250c9b04f51c971e70082740dbfeee5dd846829d541f588ad43378727  a1_7z_dll_file
996b01e15f85e165899630721a141b178a9c372b6e878012180ec9e9d4e7bd06  a1_sas_dll_file
1b19115d5ebdc216e0ab3adf2c643648cfc70a385f4caf0217c679f9f3b20342  action1_remote_exe
941695d20d82dd5d62f74b0111feb23720637202f6c797df2a02e2cb6cb6e8e3  main_service_exe

These files belongs to the RMM tool developed by Action1[2] and are signed with an "Action1 Corporation" certificate that expired in May 2026. 

The tool installs itself as a service for persistence ("A1Agent" – "Action1 Agent"), executing C:WindowsAction1action1_agent.exe.

The registy key "HKLMSoftwareAction1Agent" contains the values: CustomerId, Certificate, PrivateKey, MSI & INSTALLDIR.

The CustomerID is: 49b18106-681d-456a-b098-092e2818c09a and is connecting to the Action1 infrastructure via server[.]na-2.action1[.]com.

We are facing here the same behaviour: the threat actor abuse the cloud infrastructure of the company developing the RMM tool, probably using a free/test account.

[1] https://isc.sans.edu/diary/ScreenConnect+Client+Abused+by+Attackers/33388
[2] https://www.action1.com/remote-access/

Xavier Mertens (@xme)
Senior ISC Handler | SANS Principal Instructor | Freelance Consultant
Xameco | PGP Key

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.