Blog

Archive for November, 2019

ISC Snapshot: Search with SauronEye, (Fri, Nov 29th)

SauronEye is a search tool built to aid red teams in finding files containing specific keywords.

If you’ve ever conducted a penetration test or a red/purples team engagement, you’ve been there. You’re staring at the target agency’s SharePoints and file shares and have recognized the bloody gold mine of pwnzorship it represents. Yet, as well we know, the search features in these scenarios are less than optimal. Maybe you’ve written scripts to help with this and batched up something useful, or cranked it out in PowerShell. @_vivami’s SauronEye is here to help. SauronEye is a “search tool to find specific files containing specific words, i.e. files containing passwords.”

SauronEye features, as cited from it’s GitHub page, include search of:
– multiple (network) drives
– contents of files
– contents of Microsoft Office files (.doc, .docx, .xls, .xlsx)
– multiple drives multi-threaded for increased performance
…and support for regular expressions in search keywords. Note too that SauronEye does not search %WINDIR% and %APPDATA%. Use the -SystemDirs flag to search the contents of Program Files*. SauronEye relies on multi-threading libraries only available from .NET 4.0 and later. SauronEye is a source package, you’ll need to roll your own here. I’ll assume you already have Visual Studio Community, here’s a quick build walkthrough. I work out of my C:coding directory. In Visual Studio Community, click Clone or check out code, and give it you local path and the .git URL for SauronEye (Figure 1).

Figure 1

Figure 1: Clone SauronEye source

In Solution Explorer navigate to SauronEye.sln and open it.
In Solution Configuratons, switch from Debug to Release.
Click Build and select Build Solution.

Figure 2

Figure 2: Build SauronEye

That’s it, the resulting binary will be found in C:codingSauronEyesrcSauronEyebinRelease.

The working scenario/user case here is again one that should be very familiar to red teamers and adversaries alike. I have NEVER assessed an organization where I didn’t find information and data stored on SharePoint or file shares that enabled either the compromise of individuals or systems, or both. Password files, sensitive PII, private keys, configuration strings, you name it, you’ll find it. It is here where SauronEye shines.
To validate SauronEye’s efficacy I planted a few files throughout my file directory. These included a SQL connection string in DocumentsCache, 500 really bad passwords in a text file on my Desktop, a PII file with SSNs in Documents, and 1000 test credit card numbers in Downloads. I ran SauronEye as follows:

C:codingSauronEyesrcSauronEyebinRelease>SauronEye.exe -Dirs C:Usersrmcree -Keywords password, connection, ssn, card* -Filetypes txt, .xls, .xlsx, .conf -Contents > results.txt

SauronEye immediately landed relevant file paths, then moved on to content:

	 === SauronEye === 

Directories to search: c:usersrmcree
For file types: .txt, .xls, .xlsx, .conf
Containing: password, connection, ssn
Search contents: True
Search Program Files directories: False

Searching in parallel: c:usersrmcree
[+] c:usersrmcreeAppDataLocalMicrosoftWindowsFileHistoryData613CUsersrmcreeDocumentscacheSQLconnection.txt
[+] c:usersrmcreeDesktop500-worst-passwords.txt
[+] c:usersrmcreeDocumentscacheSQLconnection.conf
[*] Done searching file system, now searching contents

Content discovered from my planted files included the SQL connection string:

[+] c:usersrmcreeAppDataLocalMicrosoftWindowsFileHistoryData613CUsersrmcreeDocumentscacheSQLconnection.txt: 
	 Server=Pwn3dSQLServerPwnM3;Database=IMPWN3D;User Id=ImaDumass;Password=123456;

Results from the 500 worst passwords are seen in Figure 3.

Figure 3

Figure 3: SauronEye finds really bad passwords

Customer PII is uncovered in Figure 4.

Figure 4: SauronEye reveals PII

From the 1000 credit card records:

[+] c:usersrmcreeDownloads1000_CC-Records.xlsx: 
	 Jefferson Trina A Carroll Jason K Bray Denny

This is a project to watch, and definitely one to try out during your next red team engagement, penetration test, or audit/assessment. It’s guaranteed you’ll find useful results. Please use SauronEye responsibly. Vincent is committed to this project, was immediately responsive to a bug query, and deployed a fix in less than 24 hours. Please support him with bug reports, feature requests, or pull requests.

Cheers…until next time.

Russ McRee | @holisticinfosec

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

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Finding an Agent Tesla malware sample, (Wed, Nov 27th)

I was browsing through the Any Run sandbox looking through the public submissions of malware with pcaps of infection traffic from Tuesday 2019-11-26.  I found this one, and it’s tagged agentteslaAgent Tesla is an information stealer.  Based on the file name, this Agent Tesla malware sample may have been disguised as an installer for Discord.


Shown above:  The Agent Tesla malware sample I found on Any.Run.

I retrieved the pcap from Any.Run’s analysis of this malware sample, so I could review the traffic.  Agent Tesla sends an email containing information from the victim’s Window host.  In many cases, email traffic generated by Agent Tesla is encrypted SMTP, but sometimes the post-infection SMTP traffic is unencrypted.  Luckily, this example was unencrypted SMTP.


Shown above:  Getting the pcap from analysis of the malware sample.


Shown above:  Filtering on the pcap in Wireshark and finding the TCP stream to follow for the SMTP traffic (over TCP port 587).


Shown above:  TCP stream showing unencrypte SMTP traffic caused by this sample of Agent Tesla.

As shown in the image above, this sample of Agent Tesla malware exfiltrated stolen data to the email address [email protected].  I’ve filtered out what would normally be sensitive data in the above image, so if you’re curious, you can review the pcap (here’s a link again for the analysis page) and discover for yourself.


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.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Lessons learned from playing a willing phish, (Tue, Nov 26th)

Replying to phishing e-mails can lead to some interesting experiences (besides falling for the scams they offer, that is). Since it doesn’t require a deep technical know-how or any special expertise, it is something I recommend everyone to try out at least once, as it can lead to some funny moments and show us that the phishing trade doesn’t always operate in the way we might expect it to.

When it comes to phishing e-mails, unless they are successful, highly targeted, or part of a larger attack pattern of a single threat actor, most of us tend to just delete the messages and quickly forget them. But sometimes it can be quite instructive to bait the phishers and play a potential victim of the scam they thought up. Although most of us won’t be able to come close to making the attacker join our fictitious religion and send us his photograph with his breast is painted red, along with a sum of money[1], the experience can still be quite interesting and teach us a lot.

If you chose to bait phishing attackers, it is advisable not to do so from your own e-mail account but use another one – ideally a “burner” account you don’t mind losing. This brings us to one of the first things pretty much anyone who tries to bait phishers learns – unless it’s a targeted attack, the scammers don’t (for obvious reasons) check whether the e-mail address they receive a reply from was part of the list of addresses they originally send the phishing to.

If we reply to a phishing e-mail within a couple of days after receiving it, chances are that phishers will get in touch with us. Phishing messages usually ask us (again, for obvious reasons) to reply to a different address than the one we (seemingly) received it from. For run of the mill phishing attacks, most threat actors stop (or are forced to stop) using any e-mail addresses associated with a phishing campaign fairly quickly, although this is not always the case. The campaign which prompted me to write this diary actually surprised me very much in this regard. And, since it was otherwise quite “normal”, we’ll use it as an example of how phishing campaigns may progress.

It started all the way back in August with an e-mail in which the author, claiming to be an attorney of a recently deceased wealthy man, promised me untold riches if I act as a relative of the deceased in order to get his vast fortune as an inheritance. It contained the following text in both English and Spanish.

From: Ike Kekeli  
To: undisclosed-recipients:;
Subject: Hi ,
Date: 13 Aug 2019 17:29 (GMT +02:00)

Hi,

Firstly, let me identify myself without any intention of equivocation
on this business opportunity to you my name is Ike Kekeli , A
Fiduciary bank Attorney At Law ?s wish to know if we can work
together. I would like you to stand as the surviving beneficiary to my
deceased client ( Mr . Gilbert ) who made some deposit of $7.9 Million
Dollars to be transferred to any possible safe account with your good
assistance.

He died without leaving any WILL and any registered next of kin and as
such the funds now have an open beneficiary mandate. Kindly get in
touch with me through my email address ( barristerikek  gmail.com ) for
more guidelines to the repatriation of this fund.

Regards,
Attorney Ike Kekeli . ( Esq )

 

I only noticed the e-mail when I was going through my phishing quarantine nearly two weeks after it was delivered and although the e-mail wasn’t special in any way (this sort of lure is quite common in phishing), and I wasn’t holding much hope with regards to the address still being active, I decided to reply. The reaction from the attackers didn’t take long – within 10 minutes, I had another e-mail in my inbox, this time asking me for my personal information. Although this sort of reaction time puts even many professional support teams to shame, it is actually not uncommon for phishers to reply to their potential victims very quickly. Sometimes, it might take a day or two to get a reply back, but in many other cases (especially in cases of BECs), five or ten minutes may be more than enough time.

After exchanging couple of messages with “attorney Ike”, he sent me couple of forms pre-filled with the personal information I’ve provided earlier and asked me to send these to a “bank” – a different e-mail address used by the attackers. This is another quite common technique used by malicious actors as it lends the scam much more credibility if multiple “trustworthy” parties seem to be involved. The reply from the bank contained a spectacularly looking letter in a PDF from the “bank president” asking me for a copy of my ID card.

 

Sending the phishers a document can be a good way to determine their external IP address – I send the “bank” a TinyUrl link which redirected a visitor to my logger script, which, after saving the IP address of the visitor and some additional information, redirected them to what seemed to be a corrupted JPEG file. Since most phishers don’t have a high level of technical expertise or security awareness, they tend to click pretty much anything one sends them, so it didn’t take long to get a hit on the logger script and determine where the attackers were from.

The “bank” afterwards asked me to send in a filled in form with my personal information and a photo. I’m the first to admit that I can be a bit juvenile in such cases – I usually pick one of the more famous actors out there, as you may see bellow, and see whether I get any interesting reaction from the phishers. Although it is surprising, they usually don’t notice it.

It was at this point that both “Ike” and the “bank” started to ask for money – since the “bank” sent me an account number to transfer the money to (account in a different bank, then the one they were acting as, of course), I contacted the real bank with the account information and after exchanging couple of additional messages broke off the contact with the scammers. Getting the account number and providing it to the bank which hosts the account is usually the most one can do in such cases, without straying outside the reasonable ethical boundaries. It took about two weeks for the phishers to give up after I stopped responding at the beginning of September.

The most interesting part of this phishing campaign came only last week, when I received a new message from “Ike”, promising me a reward for helping him although the deal didn’t work out. That is not so unusual, what is – at least in my experience – quite unique is that the message was sent from the same e-mail address the attackers used during our original interaction.

And this is, so far, the last lesson which interacting with phishers has taught me – although I would have expected that any e-mail address used for phishing could not stay active for so long, there are some (or certainly at least one) which have been used for more than a quarter of a year and are still being actively used.

[1] https://419eater.com/html/joe_eboh.htm

———–

Jan Kopriva
@jk0pr
Alef Nula

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

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

My Little DoH Setup, (Mon, Nov 25th)

“DoH”[1], this 3-letters acronym is a buzzword on the Internet in 2019! It has been implemented in Firefox, Microsoft announced that Windows will support it soon. They are pro & con about encrypting DNS requests in  HTTPS but it’s not the goal of this diary to restart the debate. In a previous diary, he explained how to prevent DoH to be used by Firefox[2] but, this time, I’ll play on the other side and explain to you how to implement it in a way to keep control of your DNS traffic (read: how to keep an eye on DNS request performed by users and systems). For a while, I had the idea to test a DoH configuration but I had some requirements:

  • It must be transparent for users
  • DNS requests must be logged (who resolved which domain and when)
  • Local DNS zones like ‘lab.domain.tld’ or ‘iot.domain.tld’ must be supported (resolved via a local bind instance)
  • Users are protected via a PiHole[3] (against advertisements & malicious domains)
  • Integration with 3rd party tools

This weekend, I decided to reconfigure my network. Here is my current setup:

Endpoints (laptops, tablets, phones, visitors, etc) are using a PiHole instance (provided via DHCP) from their VLAN. Servers are using the normal Bind instance. PiHole forwards the allowed DNS requests to Bind. It is master and can resolve RFC1918 addresses from local zones (ex: *.lab.domain.tld). If the FQDN is unknown, it is forwarded to a local cloudflared[4] daemon via UDP/5353 that used DoH to resolve public names. To keep an eye on DNS requests, PiHole and Bind send their logs to my SIEM for further processing and reporting/alerting.

From a setup point of view, everything is running in Docker containers and, to increase my detection capabilities, my MISP instance is feeding PiHole and Bind with a daily export of malicious domains[5]. Let’s see how it works in the coming days…

[1] https://en.wikipedia.org/wiki/DNS_over_HTTPS
[2] https://isc.sans.edu/forums/diary/Blocking+Firefox+DoH+with+Bind/25316
[3] https://pi-hole.net/
[4] https://github.com/cloudflare/cloudflared
[5] https://isc.sans.edu/forums/diary/DNS+Firewalling+with+MISP/24556

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

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

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Local Malware Analysis with Malice, (Sat, Nov 23rd)

This project (Malice) provides the ability to have your own locally managed multi-engine malware scanning system. The framework allows the owner to analyze files for known malware. It can be used both as a command tool to analyze samples and review the results via a Kibana web interface. The Command-Line Interface (CLI) is used to scan a file or directory or can be setup to watch and scan new files when copied into a write only directory.

It is modular and is supported by “plugins”. Each plugin (malware scanning engine) can be installed in separate Dockers. Beside AV engines, there are other “plugins” for querying Virustotal (register with a key), hash searches using the NSRL database and Team Cymru.

The web/API UI hasn’t been added yet but you can setup a write only directory with “malice watch [dir]” option and copy the files to be scanned into it, the results of the scan can be reviewed using the Kibana UI. The documentation is here and the list of available plugins is here. Current support for OSX, Linux and Docker. This is the output viewed from the Kibana interface:

Listing the plugins: sudo malice plugin list –all –detail
Location of plugins: $HOME../.malice/plugins/plugins.toml

[1] https://github.com/maliceio/malice
[2] https://github.com/maliceio/malice/tree/master/docs
[3] https://github.com/maliceio/malice/blob/master/docs/plugins/plugins.md
[4] https://github.com/maliceio/malice/tree/master/docs/installation

———–
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.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →
Page 1 of 5 12345