It's not clear from the article (or maybe I'm missing it) but this isn't a vulnerability with PS right? The article would be the same if it "New Brazilian Banking Trojan Uses PHP", it's just a language/style that is new not what it is doing or how it's doing it AFAICT.
Yes. It seems the user executes an attachment that's a PIF file (a type of shortcut file) that writes out a PS script to the temp directory and executes powershell.exe to run it. The point of highlighting PS in the article appears to be that previous distribution of this malware used a different mechanism, not anything wrong with PS itself.
As a "corporate" sysadmin using Powershell everyday, I was always surprised that PS is not so used in the malware industry.
By the way, I find that this article[0] linked in the original post is much more interesting if you want to know more about how brazilian malwares work (BHO injection, 2FA bypass, etc.)
It took a while for powershell to be installed on most computers. It's still certainly missing on many computers (i.e. the oldest and most vulnerable).
I actually don't know whether it is installed as default in the latest Microsoft OS and patches.
That and the very easy way to analyse/reverse engineer scripts don't make a great candidate for malware.
Anyway, the windows shell is enough for trivial scripts, and one might as well write software in a real programming language for the rest.
It's been installed by default since Windows 7 and PS v2. The only version that wasn't installed by default with a Windows release was PS v1 (introduced at the same time as Vista).
Yep. There's nothing about PowerShell in particular that enables this attack apart from being able to execute code. Granted, it can do a bit more with the system than cmd could, but that's about it.
So, how the heck does a PIF file from an e-mail attachment get written somewhere it might get executed and then how the heck does it get executed? For lots of details on e-mail to illustrate how hard or at least awkward such a position and execution of such a file would be, see my long, detailed discussion of the internals of common Internet e-mail. Net, just because someone sends me a PIF file, I can see no way they could hope that I would execute it.
I'm having trouble understanding what the
OP is describing:
It looks like the OP did not make clear
just how receiving the malicious e-mail
could lead to a malware infection
(computer virus).
So, in more detail, the OP wrote
> The banking Trojan is being delivered
via a phishing campaign where emails are
masquerading as a receipt from a mobile
carrier. A malicious .PIF (Program
Information File) attachment is used to
attack the target’s PC. PIF files tell
MS-DOS applications how to run in Windows
environments and can contain hidden BAT,
EXE or COM programs that automatically
execute after the host file is run.
So, below I go step by step through how
standard Internet e-mail works and,
thereby, show that it's not easy to get a
computer virus infection just from
receiving malicious e-mail. In
particular, for the OP, I don't see how
there could have been a virus infection.
So, it appears that the OP omitted one or
more operations or steps taken by a user
and necessary to get such an infection.
For better understanding of system
security, I want to know what those steps
could be.
=== Getting Started
So, someone receives some e-mail with an
e-mail attachment that is a .PIF file.
Okay.
=== E-Mail 101
Early in my use of the Internet and
e-mail, which was also early in the growth
of the commercial Internet, I read several
of the more important standards documents.
So I was reading some of the Requests for
Comments (RFCs) of the Internet
Engineering Task Force (IETF). So I read
some RFCs for Simple Mail Transfer
Protocol (SMTP). For e-mail attachments,
I read about the Multimedia Internet Mail
Extensions (MIME).
The e-mail software I had was awful, e.g.,
it put a separate icon on my screen for
each e-mail message sent or received!
Outrageous! So, long before 33,000
e-mails, say, to pick a random number, the
screen would become relatively full! So,
I just wrote my own e-mail software.
Writing such e-mail software is actually
surprisingly easy to do: Basically in
such software are just using the standards
in the RFCs for Post Office Protocol 3
(POP3). So, to do this, it's enough to
write some relatively simple software that
communicates over the Internet the usual
way, that is, using the RFCs for
Transmission Control Protocol/Internet
Protocol (TCP/IP).
And as an alternative and without writing
any software at all, it's possible to be
even simpler: Just use the standard,
interactive, command line, TCP/IP
application program Telnet to send or
receive a file, the file having the
e-mail.
With such approaches to sending/receiving
e-mail, most possibilities for mystery
about e-mail disappear. In a word, that
approach, POP3, to e-mail is simple. In
two words, it's dirt simple. In the
sense of computer security, it should be
about as safe as anything could be; if
there is a security problem, then it is
not from the little TCP/IP or Telenet
usage but would have to be in other
hard/software.
=== E-Mail 102
So, in particular, with attachments or
not, that is, with MIME parts or not, an
e-mail message as sent or received is just
a string of bytes, 8-bit bytes, just
bytes. Computers do well handling strings
of bytes, just any bytes at all, safely,
that is, without getting infected with a
computer virus.
=== My DIY E-Mail Software
For the e-mail software I wrote, I had a
file on my hard disk for receiving e-mail.
As my e-mail software received an e-mail
message, the software just wrote
(appended) the bytes of the e-mail message
to the end of that file. Then to read the
e-mail, I could just use my favorite text
editor to read the file.
Then, for security, the text editor was
just reading a file of bytes, just bytes,
just 8-bit bytes, and trying to display
them.
Yes, when the file got too big, I started
another one. Actually, I still have that
old e-mail software and those old e-mail
files. So, looking at that old work, I
got 234 such e-mail files from about
4/1997 to 8/2005. The average file size
was 1,137,251 bytes. The total number of
e-mail messages was 29,978 (not quite the
famous 33,000). So, I used my little
e-mail software for 8 years. It worked
quite well.
=== A Nice Feature
There was a nice feature: Each e-mail
message sent or received could be
identified by just the file and a
time-date stamp within the file. So,
elsewhere in my work, that pair served as
a link or pointer to individual e-mail
messages. Then, given such a link,
anywhere on my system, in my favorite
editor I could give just one keystroke and
see the e-mail message. Nice.
=== My DIY E-Mail Security
For more on security, I very much doubt
that there exists a stream of bytes that,
when read by my favorite text editor, will
result in a virus infection. So, so far,
when receiving e-mail with the software I
wrote, I see no way my computer could get
a virus infection. That is, sure, maybe
there is a lot of malicious software in
attachments in some e-mail I received, but
that software would just be written as
bytes to that file my e-mail software
appended to. There those malicious bytes
would be and remain, harmlessly. The
malicious bytes could be read by my
favorite editor, all with full safety.
=== My DIY E-Mail and MIME
Okay, there is more we should understand:
In the RFC for MIME, an attachment can
be a file of some image, some sounds, some
video, from a spreadsheet, an Adobe
Portable Document Format (PDF) file, some
quadruple encrypted, triple tricky,
official Sky Captain National Security
Protocol, total secrets of the universe
file. But with the MIME standards, each
such attachment, as sent or received, is
just a very non threatening, essentially
harmless, really innocuous, string of
total gibberish characters in the long
standard 7-bit American Standard Code for
Information Interchange (ASCII) printable
characters.
Exercise: Look up the exact list and see
that exactly 65 such printable characters
are used.
Answer: The characters are:
ABCDEFGHIJKLMNOPQRSTUVWXYZ
abcdefghijklmnopqrstuvwxyz
0123456789
+/
So, there are exactly 64 characters. The
character '=' not in that list is used at
the end of an encoding to handle the
situation that the number of bits in the
input data is a multiple of 8 while the
number of bits represented by the 64
characters is a multiple of 6.
Right, to send an e-mail attachment, take
the string of bytes of the attachment and
convert it to those 64 printable
characters followed possibly by one or two
'=' characters. Right, just how to do
this is called base 64 encoding. And in
the exercise, we saw where the 64 comes
from.
So, in e-mail, as it is received, each
attachment is just a gibberish string of
these 64 printable ASCII characters with
possibly some characters '=' at the end.
So, all those characters, being so simple,
are easy to view with common text editors
with, yes, lots of ASCII gibberish but no
risks or dangers. And, for the users'
viewing pleasure, the gibberish is
formatted into separate lines with, <= 76
characters per line.
Then, sure, if have received e-mail with a
MIME attachment, can do a base 64 decode
to get back to the string of bytes for an
image, audio recording, video clip, PDF
file, etc.
To convert to/from base 64 encoding is
easy; writing the software is an easy,
elementary programming exercise. Long ago
I wrote such software in the old IBM
interpretive language Rexx.
=== My DIY E-Mail, MIME, and Security
So, so far in our handling of e-mail, we
have done nothing dangerous or risky;
really, there is no reasonable way that
receiving e-mail could get our computer a
virus infection.
Well, eventually attachments became more
common in e-mail. So, right, for such
attachments, with my home-brew e-mail
software, I could receive e-mail, use my
editor to put the base 64 gibberish of
each attachment in its own file, on each
such file run my little Rexx software for
base 64 decoding, and do what I was
willing to do, what risks I was willing to
take, with the resulting decoded files.
So, for an example, if the e-mail claimed
that some attachment was intended to have
file extension JPG, then I could make the
extension of the file JPG and give the
file to, say, the standard Windows Picture
and FAX Viewer. If the file was really a
JPG file, then the viewer should so
confirm and just display the image. Else
the viewer should report that the file was
not a legal JPG file. In either case,
there should be no harm done, no matter
what the heck was really in the file.
Here, of course we would have to trust the
Windows Viewer -- hopefully we could do
that.
=== E-Mail is Risky?
Yes, long early in the commercial Internet
and e-mail, there were claims that
receiving a malicious e-mail could easily
result in a virus infection. Considering
my understanding of e-mail as above and
hearing such virus claims, I was ready to
scream HOW? How the heck could receiving
e-mail be risky?
That is, according to the e-mail standards
as above, e-mail received is just a string
of bytes. The bytes are all printable.
Attachments are also printable because
they are in base 64 encoding as above.
So, such e-mail received is just harmless.
Put that e-mail and/or its attachments in
some files, and they are still harmless.
=== The OP
So, from the e-mail standards reviewed
above, it appears that the OP omitted one
or more operations or steps taken by a
user and necessary to get such an
infection.
This example is actually funny since it's one of the major topics that triggers me to tell people how much worse they make the world doing stuff like that. Thanks for adding that.
