What's new arround internet
| Src | Date (GMT) | Titre | Description | Tags | Stories | Notes |
 |
2021-11-02 18:48:08 | Going To Ground with The Windows Scripting Host (WSH) (lien direct) |
About a month ago, I was involved in an investigation that revealed
a targeted attacker using an interesting variation of a well-known
persistence mechanism - a technique that is relevant both to
incident responders hunting for evil and penetration testers looking
to add post-exploitation methods to their toolkit. Today, I'm going
to talk about this persistence mechanism and discuss some ways you
might go about identifying it in your environment. I think
that the majority of folks reading this blog have encountered
malware that maintains persistence via the startup folder. The
startup folder is a directory that may contain binaries, scripts or
shortcut files. A folder exists for each user on the system as well
as for "all users." On Windows 7, for example, the
Administrator startup folder resides at
"C:UsersAdministratorAppDataRoamingMicrosoftWindowsStart
MenuProgramsStartup". When a user successfully
authenticates, Windows will attempt to execute any binary, run any
script, or follow-up and execute any shortcut that is present within
that user's startup folder. If scripts or applications are placed in
the "all users" startup folder, these will be executed
shortly after the system boots. I often see the startup
folder used legitimately to execute maintenance scripts written in
Visual Basic or in Microsoft's batch scripting language. I also
frequently see that applications install shortcut, or LNK, files
within the startup folder that point to applications on disk.
Malicious use of this directory, however, is most often associated
with commodity malware - often accomplished by dropping an
executable into the startup folder. I've also seen a few
variants of commodity malware that install a LNK file in the startup
folder and deploy an EXE into a directory that the user can write
to, like " C: users local settings emp ". LNK
files contain several kinds of useful metadata, but for today's
purposes we're interested in LNK files as pointers to other
files. In this recent case, we identified a novel technique
that indirectly loads malicious scripts by means of LNK files in a
user's start-up folder. The LNK file was designed to invoke the Windows scripting host (WSH). The WSH comes in
both a GUI version, "wscript.exe", and a command-line
version, "cscript.exe". The WSH can interpret Visual Basic
scripts, commonly denoted by the file extension ".vbs",
and Jscripts (Microsoft's implementation of JavaScript), commonly
denoted by the file extension ".js". The malicious LNK
file invoked "wscript.exe" to interpret a JScript file
stored within a specific user's profile. Here's a cleaned-up excerpt
parsed from the LNK file using lnk-parser,
depicting the relative path to the WSH (in yellow) and an argument
(in green) which points to a JScript file:
 The JScript we found used an
ActiveXObject object to create an instance of Internet Explorer and
open a URL hosted by a code-sharing cloud service. Here's what that
looks like:
 This script connected to a
remote system that provided command and control (C2) functionality ,
which included collecting system information from the infected
machine and providing the attacker with the ability to execute
commands via the command console, "cmd.exe". During
analysis of the affected system, we found significant evidence in
URL History for the Internet Explorer browser that depicted requests
to the malicious URL |
Malware | ||
|
2021-09-14 22:44:26 | ELFant in the Room – capa v3 (lien direct) | Since our initial public
release of capa, incident responders and reverse engineers have
used the tool to automatically identify capabilities in Windows
executables. With our newest code and ruleset updates, capa v3 also
identifies capabilities in Executable and Linkable Format (ELF) files,
such as those used on Linux and other Unix-like operating systems.
This blog post describes the extended analysis and other improvements.
You can download capa v3 standalone binaries from the project's release page and
checkout the source code on GitHub.
ELF File Format Support
capa finds capabilities in programs by parsing executable file
formats, disassembling code, and then recognizing features in
functions. In versions v1 and v2, capa only understood the PE file
format, so its analysis was restricted to Windows programs. Thanks to
our colleagues at Intezer, capa
now recognizes ELF files! This means you can use the tool to identify
behaviors in malware that targets Linux computers. Figure 1 shows a
rule that describes techniques to fetch the current user on Linux.
Figure 1: capa rule identifying
capabilities on Linux
We're excited Intezer leverages capa and thrilled they are sharing
their improvements with the community. In addition to the code
updates, Intezer proposed 36 capa rules to identify various
capabilities in ELF files, such as reconnaissance, persistence, and
host interaction techniques. Please read Intezer's
blog post for more details.
New Features capa Can Recognize
As we taught capa to recognize ELF files, we also wanted rule
authors to tune their rules to find behaviors specific to different
operating systems (OS), CPU architectures, and file formats. For
example, the APIs exposed by Windows are very different from those
found on Linux systems; therefore, rules should clearly designate
which pattern to use on Windows versus Linux.
Based on discussions and feedback collected from users and
contributors, we've extended capa's rule format to describe OSes, CPU
architectures, and file formats. The rule shown in Figure 2 uses os features to distinguish techniques used to get
networking interface information on Windows and Linux. Note that the
rule is explicit about which APIs are found on each OS, making it easy
for both humans and machines to interpret the matching logic.
Figure 2: capa rule using the os feature
to distinguish OS specific features
We've also added arch (such as arch: i386 for 32-bit Intel code) and format (such as format:
elf for ELF files) features to distinguish between CPU
architectures and file formats. To learn more about these and capa's
rule syntax see the rule
format documentation on GitHub.
Unfortunately, rules with these new features are not backwards
compatible with older versions of capa. Therefore, you should prefer
to upgrade your capa installation to take advantage of our enhanced rules.
Substring Features
To make many rules easier to read, we've added a convenience feature
named substring that acts |
Malware Tool Guideline | ||
|
2021-08-12 14:57:47 | Announcing the Eighth Annual Flare-On Challenge (lien direct) |
 The FLARE team is once again
hosting its annual Flare-On challenge, now in its eighth year. Take
this opportunity to enjoy some extreme social distancing by solving
fun puzzles to test your mettle and learn new tricks on your path to
reverse engineering excellence. The contest will begin at 8:00 p.m. ET
on Sept. 10, 2021. This is a CTF-style challenge for all active and
aspiring reverse engineers, malware analysts, and security
professionals. The contest runs for six full weeks and ends at 8:00
p.m. ET on Oct. 22, 2021.
This year's contest will consist of 10 challenges and feature a
variety of formats, including Windows, Linux, and JavaScript. This is
one of the only Windows-centric CTF contests out there and we have
crafted it to represent the skills and challenges our FLARE team faces.
If you smash your way through all 10 challenges, you will receive a
prize and permanent recognition on the Flare-On website to honor your
greatness. Prize details will be revealed later, but as always, it
will be worthwhile swag to earn the envy of your peers. Prior year's
prizes were belt buckles, a replica police badge, a challenge coin, a
medal, a massive pin, and a cyber-styled skeleton key.
Check the Flare-On website for a
live countdown timer, to view the previous year's winners, and to
download past challenges and solutions for practice. For official news
and information, we will be using the Twitter hashtag: #flareon8. |
Malware | ||
|
2021-08-03 15:39:20 | capa 2.0: Better, Faster, Stronger (lien direct) | We are excited to announce version 2.0 of our open-source tool called
capa. capa automatically identifies capabilities in programs using an
extensible rule set. The tool supports both malware triage and deep
dive reverse engineering. If you haven't heard of capa before, or need
a refresher, check out our first
blog post. You can download capa 2.0 standalone binaries from
the project's release page and
checkout the source code on GitHub.
capa 2.0 enables anyone to contribute rules more easily, which makes
the existing ecosystem even more vibrant. This blog post details the
following major improvements included in capa 2.0:
New features and enhancements for the capa
explorer IDA Pro plugin, allowing you to interactively explore
capabilities and write new rules without switching windows
More concise and relevant results via identification of library
functions using FLIRT and the release of accompanying open-source
FLIRT signatures Hundreds of new rules describing
additional malware capabilities, bringing the collection up to 579
total rules, with more than half associated with ATT&CK
techniques Migration to Python 3, to make it easier to
integrate capa with other projects
capa explorer and Rule Generator
capa explorer is an IDAPython plugin that shows capa results
directly within IDA Pro. The version 2.0 release includes many
additions and improvements to the plugin, but we'd like to highlight
the most exciting addition: capa explorer now helps you write new capa
rules directly in IDA Pro!
Since we spend most of our time in reverse engineering tools such as
IDA Pro analyzing malware, we decided to add a capa rule generator.
Figure 1 shows the rule generator interface.
Figure 1: capa explorer rule generator interface
Once you've installed capa explorer using the Getting
Started guide, open the plugin by navigating to Edit >
Plugins > FLARE capa explorer. You can start using
the rule generator by selecting the Rule Generator tab at the
top of the capa explorer pane. From here, navigate your IDA Pro
Disassembly view to the function containing a technique you'd like to
capture and click the Analyze button. The rule generator will
parse, format, and display all the capa features that it finds in your
function. You can write your rule using the rule generator's three
main panes: Features, Preview, and Editor. Your
first step is to add features from the Features pane.
The Features pane is a tree view containing all the capa
features extracted from your function. You can filter for specific
features using the search bar at the top of the pane. Then, you can
add features by double-clicking them. Figure 2 shows this in action.
Figure 2: capa explorer feature selection
As you add features from the Features pane, the rule
generator automatically formats and adds them to the Preview
and Editor panes. The Preview and Editor panes
help you finesse the features that you've added and allow you to
modify other information like the rule's metadata.
The Editor pane is an interactive tree view that displays the
stat |
Malware Tool |
1
We have: 4 articles.
We have: 4 articles.
To see everything:
Our RSS (filtrered)
