Workaround for AutoIt popup window Error messagebox

Virus cured: AutoIt3.exe renamed to AutoIt3.exe.JUNK in folder C:\Users\<your user name here>\AppData\Roaming\Microsoft and used the free version of CCleaner to clean registry after rebooting and it solved a constant popup window that kept trying to open this AutoIt file and kept showing the AutoIt Error popup window with "Error opening the file" message.

Happens every so often, the above is the workaround cure, not sure if uTorrent is (innocently and indirectly) responsible or some random porn site is infecting the PC with this harmless virus / malware.

RayLopez99 wrote:
> Workaround for AutoIt popup window Error messagebox
>
> Virus cured: AutoIt3.exe renamed to AutoIt3.exe.JUNK in folder C:\Users\<your user name here>\AppData\Roaming\Microsoft and used the free version of CCleaner to clean registry after rebooting and it solved a constant popup window that kept trying to open this AutoIt file and kept showing the AutoIt Error popup window with "Error opening the file" message.
>
> Happens every so often, the above is the workaround cure, not sure if uTorrent is (innocently and indirectly) responsible or some random porn site is infecting the PC with this harmless virus / malware.

https://www.mcafee.com/blogs/other-blogs/mcafee-labs/autoit-and-malware-whats-the-connection/

Example of a dropper. You should upload a sample to virustotal.com .

https://www.reddit.com/r/Malware/comments/85n4jb/autoit_v3_scriptexe_the_shortcut/

AutoIT can even be used to check for files
being written to disk. AutoIT scripts can be text,
or can be compiled into EXEs.

https://www.autoitscript.com/forum/topic/188333-monitor-files-being-written-to-disk-in-realtime/

Their suggestion of "SHChangeNotifyRegister" would likely
be a hook into the USN Change Journal in NTFS. Many programs
can monitor what is going on with the C: file system, by
monitoring the journal. For example, the Windows SearchIndexer,
it receives notification for every file written to disk,
so that it can "index" them and add them to the search
database in real time. This keeps the search index fresh.

Perhaps Microsoft AppLocker can be used to stop that.
But it might be an enterprise feature. There is also a
Windows Defender feature for adding items to be
excluded from execution (the "robust" version of AppLocker).
AppLocker was used at first, to filter off Ransomware,
but the Ransomware guys soon defeated it and made a
joke out of it. AppLocker can be used for "innocent"
and "stupid stuff". For example, one guy used it to stop
every instance of "autorun.inf" on the computer, which
is a great way to stop one attack vector (malware on
USB sticks say).

*******

SHChangeNotifyRegister or hooking the USN journal, would
alert you to a fresh copy of AutoIT3.exe being put next to
AutoIt3.exe.JUNK . Because that's what will happen next, is
the file will come back at its leisure. When you register
for change notification, it doesn't tell you who did it,
just that it happened. And it can alert you in say, 50 milliseconds
or so, if a running program checks for such a thing. Since
it's event-based, it doesn't even have to "chew cycles"
if you write a program to do that. It can sit quietly,
and only "do something" in response to a new USN journal
entry. The USN journal in a sense, is a "broadcast" mechanism,
because four programs can find out in the same 50 milliseconds,
that a particular file has been written. The SearchIndexer for
example, listens to all events of that type, and applies
"directory filters" to determine which entries it has to act
on. An entry in the same directory as the Search Index file
Windows.edb, might be excluded from indexing.

A more powerful technique, uses ETW. Not only can it record
"hey, autoit was just written in that folder again", it
can tell you "PID 3456 just wrote AutoIT to that folder".
The Sysinternals.com Process Monitor, consumes ETW events
and logs them, but that is too heavyweight for the simple
task you need done. You say this shows up at a "low rate",
and the perp doing that knows you could use ProcMon to detect
the source of the write. ProcMon stores too much data, to
be left running all day, and besides, you have to scan
through the output later, to find the entry, and by then,
the PID might have exited to hide its tracks.

Articles like this, just tell you of the possibility of
having your own "debugger". This will chew cycles to some
extent, and isn't quite as much of a free lunch as the
Change Journal Notification mechanism. Hooking the
entire ETW stream (as if you were a copy of Process Monitor),
would be computationally expensive.

https://docs.microsoft.com/en-us/windows-hardware/test/weg/instrumenting-your-code-with-etw

*******

Summary: At least scan the damn thing, and see if it's a
known autoit-type pest. Virustotal.com . It's very
easy for these jokers to write an infinite number
of unique files like that.

I don't think placing that file in "Microsoft" like
that is "legit". Microsoft would not use AutoIT in
a product - they'd just write code to do it. Their
own code or tool.

In the McAfee article, see the line:

"I used myAut2Exe, an open-source AutoIt decompiler"

If the file is innocent, it would easily decompile to source,
you could read it, and intuit what program dropped it.

Paul