www.trustwave.com Open in urlscan Pro
52.151.96.240  Public Scan

Form analysis
5 forms found in the DOM

<form data-hs-cf-bound="true"><span class="fieldset">
    <p><input type="checkbox" value="check" id="chkMain" checked="" class="legacy-group-status optanon-status-checkbox"><label for="chkMain">Active</label></p>
  </span></form>

---

GET /en-us/search/

<form oninput="autoSuggest(q.value)" method="get" target="_self" action="/en-us/search/" _lpchecked="1" data-hs-cf-bound="true">
  <div class=" site-header-search-mobile" id="search-box">
    <i class="fe fe-search text-darkest"></i>
    <input id="search" value="" type="text" class="form-control" name="q" placeholder="Search trustwave.com" autocomplete="off">
    <div id="search-bar">
      <ul class="ul-list list-unstyled result-list" id="suggestresults"></ul>
    </div>
  </div>
</form>

---

GET /en-us/search/

<form method="get" target="_self" action="/en-us/search/" data-hs-cf-bound="true">
  <div class="site-header-search-main">
    <i class="fe fe-search text-darkest"></i>
    <input type="text" class="form-control form-control-lg" id="q" name="q" placeholder="Search trustwave.com">
  </div>
</form>

---

GET https://www2.trustwave.com/Subscription-Center-Subscribe.html

<form method="get" target="_blank" action="https://www2.trustwave.com/Subscription-Center-Subscribe.html" data-hs-cf-bound="true">
  <div class="row g-7">
    <div class="col-md-6 col-lg-7">
      <input type="text" class="form-control" name="Email" placeholder="Email Address">
    </div>
    <div class="col-md-6 col-lg-5">
      <button class="btn btn-primary w-100" type="submit">Subscribe</button>
    </div>
  </div>
</form>

---

<form data-hs-cf-bound="true"></form>

---

Text Content

Cookie Notice

We use cookies to provide you a relevant user experience, analyze our traffic,
and provide social media features. Privacy Policy


Close
GOT IT


 * Your Privacy

 * Strictly Necessary Cookies

 * Performance Cookies

 * Functional Cookies

 * Targeting Cookies

 * Privacy Policy

Privacy Preference Centre

Active

Always Active



Save Settings

Allow All

Overview of the Cyber Weapons Used in the Ukraine - Russia War Learn More
 * Contact Us
 * Login
   Login
   Fusion Platform Login
   What is the Trustwave Fusion Platform?
    * MailMarshal SEG Login
    * Legacy TrustKeeper Login

 * Incident Response
   Incident Response
   
   EXPERIENCING A SECURITY BREACH?
   
   Get access to immediate incident response assistance.
   
   24 HOUR HOTLINES
   
    * AMERICAS
      
      +1 855 438 4305
   
    * EMEA
      
      +44 8081687370
   
    * AUSTRALIA
      
      +61 1300901211
   
    * SINGAPORE
      
      +65 68175019
   
   Recommended Actions
 * 

 * Services
   Services
    * 
      Managed Detection & Response Eradicate cyberthreats with world-class intel
      and expertise
    * 
      Managed Security Services Expand your team’s capabilities and strengthen
      your security posture
    * 
      Consulting & Professional Services Tap into our global team of tenured
      cybersecurity specialists
    * 
      Penetration Testing Subscription- or project-based testing, delivered by
      global experts
    * 
      Database Security Get ahead of database risk, protect data and exceed
      compliance requirements
    * 
      Email Security & Management Catch email threats other miss with layered
      security & maximum control
   
   View All Trustwave Services
 * Solutions
   Solutions
   
   BY INDUSTRY
   
    * Education
    * Financial Services
    * Government
    * Healthcare
    * Hotels
    * Legal
    * Manufacturing
    * Retail
   
   BY REGULATION
   
    * Data Privacy
    * CMMC
    * FISMA
    * GDPR
    * GLBA
    * HIPAA
    * ISO
    * SOX
   
   BY TOPIC
   
    * Microsoft Exchange Server Attacks Stay protected against emerging threats
    * Rapidly Secure New Environments Security for rapid response situations
    * Securing the Cloud Safely navigate and stay protected
    * Securing the IoT Landscape Test, monitor and secure network objects

 * Why Trustwave
   Why Trustwave
    * The Trustwave Approach A focus on threat detection and response
    * Awards and Accolades Recognition by analysts and media outlets
    * Trustwave SpiderLabs Team Researchers, ethical hackers and responders
    * Trustwave Fusion Platform Unprecedented security visibility and control
    * SpiderLabs Fusion Center Our cybersecurity command center
    * Security Operations Centers Distributed worldwide defense nodes

 * Partners
   Partners
    * Technology Alliance Partners Key alliances who align and support our
      ecosystem of security offerings
   
    * Trustwave PartnerOne Program Join forces with Trustwave to protect against
      the most advance cybersecurity threats
    * Register
      Login

 * Resources
   Resources
   
   BLOGS
   
    * Trustwave Blog
    * SpiderLabs Blog
   
   UPCOMING
   
    * Webinars
    * Events
   
   MEDIA & ASSETS
   
    * Document Library
    * Video Library
    * Analyst Reports
    * Webinar Replays
    * Case Studies
    * Trials & Evaluations
   
   NOTICES
   
    * Security Advisories
    * Software Updates
   
   HELP
   
    * Contact
    * Support

 * 
 * Request a Demo

Loading...

BLOGS & STORIES


SPIDERLABS BLOG

Attracting more than a half-million annual readers, this is the security
community's go-to destination for technical breakdowns of the latest threats,
critical vulnerability disclosures and cutting-edge research.


ALINA: CASTING A SHADOW ON POS

access_timeMay 08, 2013
person_outlineJosh Grunzweig
share
 * 
 * 
 * 

Over the pastfew months, a number of malware families targeting Point of Sale
(POS) systems have been discussed. First there was Dexter (Seculert /
SpiderLabs), then there was its big brother vSkimmer, and more recently there
was Dump Memory Grabber / BlackPOS. One of the most interesting threads of
commonality between these samples is the command and control (C&C) structure
used between them. Utilizing a C&C communication channel for data exfiltration,
while previously rare, has become more and more common in POS malware. I'd like
to use this blog post to discuss another similar sample that I recently got the
chance to look at, named Alina. We've seen Alina on a number of active forensic
cases in the past few months, which is how I was originally made aware of this
malware family.

Alina is not completely unknown in the reversing community. Xylitol has a nice
writeup on a slightly older version, which you can find here. While an excellent
read, I'd like to use this opportunity to dig into the mechanics of the malware
further. There are a number of versions of the Alina malware family. For this
post, I'm going to focus on version 4.0, which looks to have been created on
February 7th based on the PE timestamp information. I have some newer versions,
but I'm going to hold off talking about those until my next blog post, where I
will discuss the evolution of this malware family and the changes made between
revisions. So without further adieu, let's dig in.







STARTUP

Alina has the ability to be run with a few different arguments. If the following
argument is provided, the malware will attempt to delete the specified file
during execution.

alina=<path_to_executable>

Additionally, it will skip the installation process. Both this argument and the
installation process are described in further detail later on. Alina can also
take the following argument, which will alert Alina to update itself with the
executable specified.

update=<orig_exe>;<new_exe>

In other words, we're updating the malware to a (presumably) newer version when
we see this argument.

By default, Alina will attempt to install itself to the victim machine.

INSTALLATION

Installation is a multi-step process. Like many other pieces of malware, Alina
makes use of the HKCU\Software\Microsoft\Windows\CurrentVersion\Run registry
key. However, unlike many other samples, this key is set to a random name from
the following list:

 * java
 * jusched
 * jucheck
 * desktop
 * adobeflash
 * win-firewall
 * dwm

If one of these keys are already found present on the system, it is deleted and
a different name is used in its place. Additionally, the associated executable
file that registry key pointed to is also deleted. This technique is essentially
used to ensure multiple copies of Alina are not installed simultaneously.

Once one of the names above are chosen, and the registry key is set, the malware
will then attempt to copy itself to the victim user's %APPDATA% directory using
that name plus '.exe'. So, for example, if Alina decided to install itself under
the 'java' name, it would copy itself to %APPDATA%\java.exe.

Once persistence has been achieved using this technique, the malware proceeds to
call this newly copied executable with the argument of
'alina=<path_to_original_executable>'. As you may remember from earlier, this
argument instructs Alina to delete that executable file. So in essence, Alina
copies itself to a different location and instructs that new copy to delete the
original when it's run. Just in case I've confused anyone, I've attempted to
illustrate this process below:



EXECUTION

So at this point Alina is installed and persistence on the victim machine is
set. Now we get into the 'meat' of the sample. I.e. what does this thing
actually do. Well, as mentioned at the beginning of this post, Alina is POS
malware, which means it will attempt to target track data. Alina is in short a
simple memory dumper with a lot of bells and whistles.

Alina, like many other memory dumpers, makes use of the Windows API call
CreateToolhelp32Snapshot() and Process32First() / Process32Next() in order to
iterate through every process on the machine. In order to expedite the process
of dumping memory, Alina utilizes a blacklist approach to ignore well-known
processes that may be running on the system. Specifically, the following process
names are ignored:

 * explorer.exe
 * chrome.exe
 * firefox.exe
 * iexplore.exe
 * svchost.exe
 * smss.exe
 * crss.exe
 * wininit.exe
 * steam.exe
 * devenv.exe
 * thunderbird.exe
 * skype.exe
 * pidgin.exe

If the process isn't in this list, it is added to a list of processes that will
be subsequently scanned for track data. Once this process completes, the malware
then proceeds to iteratively read through the process' memory and utilizes a
series of regular expressions to determine if track data is present. As another
technique to speed things up, the malware author decided to only look at memory
pages that have the read/write attribute. If we take a second to think about the
logic behind this, it makes complete sense. If a process is handling track data,
it will have to read and write to the memory location where this data is stored.
This allows the malware author to only concern (him/her)self with sections of
memory that fit these attributes. The malware author is also concerning himself
or herself with memory that is accessible to the process, further saving time.

I mentioned earlier that regular expressions were used by Alina to find track
data. Specifically, the following three regular expressions are used to find
information that it deems to be important:



Once Alina discovers any interesting data, it begins the exfiltration process.

EXFILTRATION

Exfiltration takes place over plain HTTP in the form of a POST request. I hope
you'll forgive me in not revealing the server IP addresses or domains, but
unfortunately this information has to remain confidential at this time. For what
it's worth, plain HTTP is still by far one of the most common exfiltration
channels we at Trustwave SpiderLabs see when looking at POS malware. To be fair,
HTTP is easy to implement, and it works, so there's no real need for these
attackers to reinvent the wheel per se. We have begun seeing much more advanced
techniques for data encryption and exfiltration; however, these situations are
still considered outliers.

Before exfiltration takes place, Alina encodes the data using a simple XOR key
of "0xAB", and then proceeds to convert this data to its hex representation.
This prevents the casual network administrator from easily determining what data
is being sent across the wire, and also ensures that all data is within the
ASCII range. We can see an example of this later on, along with a simple
decryption routine that shows us the original data.

Alina has a number of POST parameters that contain various pieces of information
(described in more detail in the C&C section). The parameter we care about below
is the 'ldata'/'cdata' param (Log Data / Card Data respectively).

LOG DATA EXAMPLE



CARD DATA EXAMPLE



Using my favorite scripting language (Ruby), we can easily extract the original
data.

LOG DATA DECODE



CARD DATA DECODE



I briefly mentioned the other POST parameters in these exfiltration requests.
Let's look at them in more detail. Through simply deduction, I've been able to
determine the meaning behind a number of these parameters, which I've outlined
below:



In the event a correct request is made to the C&C server, it will respond with a
666 status code, which is extremely odd for anyone that is familiar with HTTP.

Those of you reading this blog post that are more awake than your sleepy friends
might notice the 'd' (Download) above, which I haven't spoken about yet.
Remember way back in the beginning of this blog post where I talked about how
Alina can take the 'update=<orig_exe>;<new_exe>' argument, and has the ability
to update itself? That's where this download option comes into play. Every 'x'
seconds Alina will make this POST request and see if there is a new version
available.

If there is a new version available, we will see the remote server reply with
data in the following format:

iu:<update_interval>:<http_url>


The 'update_interval' parameter specifies the time to wait between making the
update request. This value is read in as seconds. In order to add a bit of
randomness to prevent detections from network-based security products that may
look for repeated patterns, the author adds a random value between 0 and 9
seconds to this value. By default, Alina is configured to set this update
interval to 300 seconds. Therefore, by default, we will see these update
requests every 300 to 309 seconds.

The second parameter specifies the location of the updated copy of Alina. This
file is downloaded to the %TEMP% directory (using a random 10 letter name), and
the malware updates itself with this file using the 'update=' technique we saw
in the Startup section of this blog post.

I realize this write-up is already becoming somewhat lengthy, but there's one
more item I'd like to talk about before I wrap things up. The following response
can be provided by the server when a log message is sent:

li:<log_level>:<log_interval>

The log_level parameter specifies the level of logging used by the Alina
malware. By default, this value is set to '2'. Setting this to '0' will
configure Alina to a debugging state, where all messages will be uploaded via a
series of POST requests. I've shown some of these messages below (it's quite
noisey):



The log_interval setting is used very similarly to the update_interval option
used previously. This setting specifies the amount of time to wait between when
logs are uploaded. By default this value is set to 120 seconds. A random value
between 0 and 9 seconds is added to this in order to prevent predictable POST
requests.

CONCLUSION

Overall, Alina is a pretty interesting family of POS malware, simply because of
the C&C structure it employs. Alina does not appear to be installed on victim
machines in any non-standard way. Weak remote access passwords seem to be one of
the largest ways this malware is spreading. This should come to no surprise to
anyone who has read our most recent Global Security Report, as this method of
entry accounted for 47% of all breaches we've investigated this past year.

As we see POS malware authors evolve and continue to improve, it is likely that
a C&C structure will become increasingly common. While it is not my intention to
scare anyone reading this, the prevalence of automation with regard to control
and exfiltration should help to paint a picture of the currently threat
landscape, as hackers are continuing to gain access to POS devices across the
globe. If you are responsible for managing a POS device, please be sure to set a
strong remote access password, apply any necessary patches, remove unnecessary
services, and follow general security practices to help prevent this sort of
malware from being installed on your device.

With that said, thanks for reading, and be sure to keep any eye out for my next
post, where I will go into the evolution of Alina, and how the author(s) have
continued to improve and tweak the malware over the course of the past seven
months.

Continue Reading "Alina: Following the Shadow Part 1".


RELATED SPIDERLABS BLOGS

RETALIATION BY THE PRO-RUSSIAN GROUP KILLNET

SpiderLabs Blog

2022 TRUSTWAVE SPIDERLABS TELEMETRY REPORT

SpiderLabs Blog

ORACLE SBC: MULTIPLE SECURITY VULNERABILITIES LEADING TO UNAUTHORIZED ACCESS AND
DENIAL OF SERVICE

SpiderLabs Blog


STAY INFORMED

Sign up to receive the latest security news and trends from Trustwave.

Subscribe
English German (Deutsche) Japanese (日本語)

 * Leadership Team
 * Our History
 * News Releases
 * Media Coverage

 * Careers
 * Global Locations
 * Awards & Accolades
 * Trials & Evaluations

 * Contact
 * Support
 * Security Advisories
 * Software Updates

 * Legal
 * Terms of Use
 * Privacy Policy
 * Copyright © 2022 Trustwave Holdings, Inc. All rights reserved.

Loading



HELP US STOP THE ROBOT UPRISING

This is a bot-free zone. Please check the box to let us know you're human.




THANK YOU

Download Now

--------------------------------------------------------------------------------

Read complimentary reports and insightful stories in the
Trustwave Resource Center


THANK YOU

One of our sales specialists will be in touch shortly.

--------------------------------------------------------------------------------

Read complimentary reports and insightful stories in the
Trustwave Resource Center