Are my AutoIt exes really infected?

[Exit]

@obiwanceleri 
It is best not to use an EXE file, but a CMD file.
This is very easy to do with Au3toCmd. Just look in my signature.

[Skeletor]

I had this issue until I came across @argumentum digital signing tool.

Digitally Signing Your executable

[gi_jimbo]

I'm not a regular contributor here but if the @argumentum digital signing tool works, I think it would be good to add it to the "AutoIt and Malware" page (https://www.autoitscript.com/wiki/AutoIt_and_Malware) as well as the "solution" post on this thread.

Edited November 16, 2022 by gi_jimbo
clarification

[62mkv]

See for example here:
https://www.joesandbox.com/analysis/722827/0/html

and here:
https://www.virustotal.com/gui/file/8b7098c44275d0203c23f2ce56c0e913c0d6b6d2264bc537e8a9f0a9f07badc9/community

and here:
https://cuckoo.cert.ee/analysis/3853341/summary/

Maybe it makes sense to mention on the Downloads page and/or Wiki? So people are not getting too frustrated.

 

Or even reach out (if possible) to at least some of community resources to ask them to whitelist the AutoIt itself, by SHA256 maybe

[JLogan3o13]

7 hours ago, 62mkv said:

Maybe it makes sense to mention on the Downloads page and/or Wiki? So people are not getting too frustrated.

Wouldn't curb things as much as you might think. We have tried things like that in the past; there is even an entire thread dedicated to false positives that people see, why the occur, and what to do about them. Yet people continue to post issues they encounter because the don't stop to read. 

[kjpolker]

Not too sure if this is the kind of feedback this thread is looking for but as of lately I have been getting Windows Defender to flag my executable. This is a exe I have been using for years written entirely by me of course, not even additional UDF's outside of the included functions. Trojan:Win32/Bearfoos.A!ml

Edited July 12, 2023 by kjpolker
Added keywords

[CYCho]

Hiding an AutoIt GUI with WinSetState Triggers a False Detection

I think I found at least one of the reasons for false detection by Windows Defender. A couple of years ago, I submitted my zPlayer.exe to Microsoft Defender ATP team for malware analysis and they removed the detection. I repeated this process several times whenever I made small changes in the code. After about 10 times of this process, the false detection stopped and I thought  I was, sort of, given a freedom to make whatever changes I wanted. But it abruptly changed recently and Windows Defender statrted to flag my exe again. So I submitted the file again, and they said they had to maintain the detection. I compared the codes of the last previous version, which was not detected, with the current one and I found a clue. My program has video control GUI on top of the video image created by winmm.dll. The current version has a new function to hide the video image including the video control, and I used WinSetState command for both of them. The video image is not my GUI so GUISetState does not work on it anyway. I thought it would be OK to use WinSetState for the video control as well. And that was the mistake. Just out of curiosity I replaced WinSetState with GUISetState for hiding the video control and the false detection stopped. So the lesson I learned is: do not hide an AutoIt GUI with WinSetState.

Edited September 28, 2023 by CYCho

[Shark007]

To follow up with another possible issue I noticed tha triggers false positive is how arrays are formed.

This will trigger false positives,
Local $arrName = ['3G1', '3G2', '3G3', '3G4', '3G5', '3G6', '3G7', '3G8', '3G9']

This does not trigger false positives,
Local $arrName[9] = ['3G1', '3G2', '3G3', '3G4', '3G5', '3G6', '3G7', '3G8', '3G9']

[HAL9000]

Microsoft Defender detect  SQLite3_Setup_3.27.2.0.exe as trojan  in https://www.autoitscript.com/autoit3/pkgmgr/sqlite/

and MalwareBytes detect SQLITE3_SETUP_3.22.0.0.EXE as Generic.Malware.AI.DDS

Edited December 24, 2023 by Jos
Link changed.

[argumentum]

Publisher:  Unknown publisher

I think there's a push for having everything "known", as in who made it.
Even corporate PCs will be changed/replaced to those that have TPM. The CPU serial number was rejected by the community but now with all those "data hack/stolen/CallItWhatYouWill", the push, based on fear ( in my view ) to accept a "safe" everything, all it does is to have everything known. Who made it. Who is liable.
That is my conclusion, even tho each aspect have has it's own story line that will clearly toss away what I come to understand as superstition. My 2 cents.

Bottom line, software wise, is to apply an "Extended Validation (EV) Code Signing" or have a high volume of samples running around to ramp up the credit score fame score. Again, my 2 cents.

[Jos]

26 minutes ago, argumentum said:

Bottom line, software wise, is to apply an "Extended Validation (EV) Code Signing"

True, but that comes at a cost and I am only willing to provide my time to this and other projects.  

[Skdp]

Hello, everyone. I have been using AutoIt for some time now and am quite satisfied with it, as it is not overly complex and offers quite advanced features. Unfortunately, I have encountered false positives in scripts compiled with AutoIt, especially when I upload them to VirusTotal. It would be ideal if antivirus companies could find a definitive solution to these issues.

On the VirusTotal website I noticed that “AutoIt3_x64.exe” received a negative rating of -30 from some users, which seems unjustified to me given its low detection rate and overall notoriety. In fact, it is one of the executables with the lowest number of detections ever.

I abandoned AutoHotkey because I didn't like their GPL licence, as well as their confusing syntax, which is more suited to simple automation than actual programming. As a developer, I believe it is important to have the freedom to choose the licence for my source code, so that I can decide whether it should be open source or closed source, depending on the case.

Edited October 2 by Skdp
Simplified comment

[Skdp]

On 8/19/2024 at 12:24 PM, Skdp said:

I often find myself reporting incorrect detections, and it's quite unnerving.

It's been two weeks since I reported the false positives, but they haven't even responded. Unfortunately, Au3toCmd creates cmd files, not exe files. I'll have to compile the scripts in 64-bit, but they won't work on very old PCs. In any case, I've noticed that false positives are drastically reduced by signing the executable (even to self-signed).

Edited October 2 by Skdp
Simplified answer and problem solved

[argumentum]

7 hours ago, Skdp said:

... if AutoIt.exe is incorporated into own software product (just to interpret scripts) it can only be distributed, correct?

You can legally distribute the script as EXE or AU3 or A3X as that is your product.
AutoIt is not your product hence you are not free to distribute it or bundle it, UNLESS it carries AutoIt's own EULA and the user agrees to that too. ( otherwise you are installing another product the user may not agree to )

... legally speaking, according to my interpretation of the link you provided. Never read the thing until now.

Am not a lawyer in your country, nor in mine. These are my interpretations and this is not to be understood as legal counsel.

As a side note, it be sensible to add something like:

in case something goes wrong with your script. ( I put that one together so I may be bias in the example  )

[rcmaehl]

A released a new version of one of my programs recently and of course the 32-bit version is triggering all sorts of False Positives. I did some diving into result details and there ARE a couple things the interpreter or default functions seem to do that tag "Medium Risk" MITRE rules.
 

• "User-agent is suspicious or fake" (Fixable with HttpSetUserAgent set to something believable)
• "Collects information to fingerprint the system" (MachineGuid is read at some point)
• "Exhibits possible ransomware or wiper file modification behavior: overwrites_existing_files" (FileInstall or some other function sometimes overrides its own temp\aut####.tmp files)

I haven't tested every single function so I'm sure there's more, but reviewing and minimizing what functions you use that cause Medium or higher MITRE detections will these help reduce false positives.

 

HOWEVER, The BIGGEST issue of almost all the default (~20/~70) 32-bit compiled Virustotal false positives have are the fact that AutoIt can, by default:

"electronically spy on the user’s activities (intercept keyboard input, take screenshots, capture a list of active applications, etc.)"

(for some reason 64-bit compiled applications don't really have this issue)

It would be nice if the compiler had the option of compiling in "automation mode" with all the bells and whistles, or a "application mode" that breaks automating + execute(), but this has been discussed over and over again as not happening.

Edited October 10 by rcmaehl

[argumentum]

44 minutes ago, rcmaehl said:

It would be nice if the compiler had the option of compiling in "automation mode" with all the bells and whistles, or a "application mode" that breaks automating + execute(), but this has been discussed over and over again as not happening

And the reason is ( drum roll ): is an interpreted language. Otherwise the stub that loads the script would have to be changed and have a stub for every feature to be included or not.

Share the source in GitHub and have a free service ( for open source ) sign the compiled script. That should lessen the impact.
If is private code, then pay for signing the exe ?

I too would love to have no issues with my scripts. And is not just us, this guy from notepad++ went Self-signed. 🤷‍♂️

 

[mlibre2]

These "false positives" are "temporary" well some, I have noticed that in the first analysis the alerts usually increase, after a few days they decrease and they are automatically added to the white list