Enlarge / The US House of Representatives. (credit: Wally Gobetz / Flickr)

On Wednesday, Republican lawmakers committed a major breach of security guidelines when they carried cell phones as they tried to force their way into a secure room where a closed-door impeachment hearing with a Defense Department official was taking place.

At least one House member, Rep. Matt Gaetz of Florida, got inside the Sensitive Compartmented Information Facility (SCIF) in the basement of the House of Representatives. Despite strict rules barring all electronics inside such closed-off areas, Gaetz openly tweeted: "BREAKING: I led over 30 of my colleagues into the SCIF where Adam Schiff is holding secret impeachment depositions. Still inside—more details to come."

BREAKING: I led over 30 of my colleagues into the SCIF where Adam Schiff is holding secret impeachment depositions. Still inside - more details to come. https://t.co/fHhqkZ6x3Z

— Rep. Matt Gaetz (@RepMattGaetz) October 23, 2019

A picture published by The New York Times showed a man identified as a House Republican holding up his phone as if taking pictures or video as he entered the secure room. A sign on the door of the room said, "Cameras and other recording devices prohibited without proper authorization." The room has lockers outside the doors where people are required to store electronics before entering.

Read 9 remaining paragraphs | Comments

Trying to experiment with cutting edge security tools, without breaking the bank, often leads me to used equipment on eBay. High-end enterprise equipment is usually available at a bargain-basement price. For experiments or use in a home/lab network, I am willing to take the risk to receive the occasional "dud," and I usually can do without the support and other perks that come with equipment purchased full price.

Lately, I have been looking at some of Gigamon's "Gigavue" appliances, which have become available at very affordable prices. After I received the device, I did a quick inventory of its hardware components and configuration. Pretty much immediately, it became apparent that the device was not properly wiped. Sadly, this is a very common occurrence. The configuration of the device led me to the prior owner of the device, which turned out to be a company close to where I live. After contacting them, I returned the device to them to allow them to investigate the failure in their decommissioning procedure. I didn't do much analysis myself of this particular device before returning it. Still, it was kind of interesting how it arrived a few miles from its original home via a surplus equipment seller in a very different part of the country.

But... this left me one Gigamon short. So I did purchase a second one from a different eBay seller. Again, this device arrived "untouched" (but luckily with the default password, which was in particular nice since I couldn't get the serial console to work). Again, this device had an intact configuration, which included pretty much a detailed network map. But this time, I wasn't able to quickly identify the original owner, so I decided to take a quick look at what can be learned from these devices.

As one would expect, these devices are "servers." What differentiates them from regular servers is that the only significant persistent storage is a 2GByte SDCard. I was a bit surprised by this given the "iffy" reputation of SDCards. I have had plenty of them fail over the years and would have expected a bit "more" in a device in this price class. But I guess it does the job. The SDCard is easily removed and imaged.

So far, I haven't gotten around to a full analysis of the image, but the image includes the firmware and at least some of the configuration of the device. Of course, the configuration is also easily explored via the web-based GUI of the command line interface.

I covered one company name in the image above that may indicate the original owner (but it could also be a link to that company's service. Not clear based on the label used). 

In addition to the configuration, I was also able to recover a partial syslog from the device, listing the private IP of the system from which the administrator connected to the system.

Interestingly, the administrator account used (not the default "root" account) was still configured, but the root password was set to the default password. I find it unlikely that just the root password was reset, and the remaining configuration was untouched. Gigamon does provide two commands to possibly wipe the configuration:

• sd_format: This command *should* format the SD card. But it is not clear if it will overwrite/wipe any content.
• reset system factory-default: According to the manual, this will reset the device to factory default.
• Via the serial console, the device can be reset using the "fconfig rstrtac true" command at the boot prompt. This process does not require a password and is used to reset the "root" password. It may not reset the configuration (I will have to try this out once I got the serial console working).

I did not find any customer data / PII on the systems. The risk is probably best classified as "information leakage." An attacker could certainly obtain valuable intelligence from the configuration, maybe even deduct usernames and passwords for other devices.

Lesson learned: A lot of people are talking about "Supply chain security" these days. Your supply chain doesn't end once you receive a piece of equipment. The decommissioning process and any vendors used as part of it should be considered part of the supply chain.

I will follow up on this diary once I have more time to explore some of the settings and options. Let me know if you have attempted this before and have any insight, or if you have similar stories to share.

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

I while back I posted a "part 1" story on DNS and DHCP recon ( https://isc.sans.edu/diary/DNS+and+DHCP+Recon+using+Powershell/20995 ) and recent events have given me some more to share on the topic.

There's been a lot of interest in collecting DNS information from client stations lately (specifically with sysmon), but I'm still seeing lots of value in using the DNS logs we've already got centrally positioned in many organisations.   Let's consider a typical windows based company, with DNS implemented on the Domain Controllers.

Let's check the DNS diagnostic / audit setup using PowerShell (this server is close to the defaults):

So by default we're not logging DNS requests or responses. To fix this, navigate to DNS / Server Properties, and you'll find most of these settings are available in the GUI.  Note that you can monitor requests and responses separately - this can be valuable depending on what you are looking for, and that DNS in a moderately sized company can generate GB's of logs per day (roughly half of the firewall log size in many "typical" organizations)

Once you have some logs, they're in %systemroot%\system32\dns\dns.log.  To ingest this log in PowerShell (just pulling the dns packet logs):

This gets you a list of text strings.  Let's convert this fixed-length (more or less) text fields to CSV, then to a variable list (AKA usable objects)

Now we have it in a usable format!  This likely took a while - PowerShell will only use a single core (unless you set up jobs etc), and it's not the speediest of text processing tools.  A 500,000 line log file took me a solid 2 hrs to process.

Just for a quick check, let's see if we have any hosts making queries for WPAD (ouch!).  In most shops you'd hope that this would be zero, or at least a low number.
First collect all the queries received to "anything wpad"

Let's narrow it down to "offending workstations" and get a count:

OK, trouble in paradise, that's pretty much the entire station count here!  This environment needs a GPO to say "no proxy here", or else a GPO that explicitly sets the proxy.

Now do a group by A record and requesting station / uniq.  In this situation there are 3 different particpants in a merger (two merged companies and one parent):

Looking at the dns queries themselves, which ones are the "oddballs"?  In most organizations, a one off DNS request is often an indicator of malware activity, or at least an indicator of something that should be investigated.  Picking the first "n" in the list, who is querying for those hosts?.

Let's sort by count, and pick the first 15.  Note that all the single-query counts are "2", because both the send and receive packets are logged.

hmm  - nothing suspicious about those domain names :-(  ... often we'll see ad hosts and malware sites in this list (not that they don't coincide more than we'd like).  Those random-string hostnames with the internal organization's domain name (elided to "company.com") are very disturbing.  None of those domains exist - it looks very much like someone is resolving for random CN's and the host is appending the internal domain.  Either that or it looks like some of the  "fast flux" malware from years gone by.
Digging deeper into this, for example with:

yup - you guessed it, all of those "odd" DNS requests came from the same host!  This one host was making thousands of requests per hour to invalid hostnames, accounting for roughly 10% of the DNS traffic in the organization.  The IR / workstation team is looking at this host next, but if you've seen this pattern please do help fill in the blanks - tell us what you can in our comment form.  So far it does NOT look like another DNS server that might be forwarding requests from infected workstations - it's looking like a server or workstation of some type.

This is a great way to start investigating your DNS activity for free in a Windows environment.  If you find this useful, you might consider scripting and scheduling some of this in your organization.  Or rather than parsing this manually, consider feeding your DNS logs to a SIEM - something you can also do for free (look at SANS 455 and SANS SEC 555 for more info on that)

If you've used methods like these and have found something interesting, or if you've seen the "odd" pattern of requests described in this story, please do share using our comment form (as far as your NDA will let you that is).

========== update ==========

It turns out that the "odd" dns requests were all from a "cloud managed" ethernet switch.  Since this is the only switch of hundreds doing this, we're figuring that it's infected with something.  Since these are all intel / linux machines with a switch bolted to it under the covers, that's not a huge stretch.  So the request still stands - if you've seen requests like this in your environment, please do use our comment form to carry this conversation forward!

===============
Rob VandenBrink
rob <at> coherentsecurity.com

Update Alert!  Patches are out for VMware VCSA (information disclosure in backups and restore) https://www.vmware.com/security/advisories/VMSA-2019-0018.html

Also a DOS issue in ESXi, Workstation and Fusion: https://www.vmware.com/security/advisories/VMSA-2019-0019.html

I've written a couple of diary entries about scdbg, a Windows 32-bit shellcode emulator.

If you're not familiar reading assembly code or machine language, scdbg can help you understand what shellcode is doing, by emulating it and reporting relevant Win32 API calls.

By default, scdbg assumes that the shellcode's entrypoint is the first instruction, e.g. position 0. That's not always the case, and you can use option -foff to provide a different position (offset). But this assumes that you know where the shellcode's entrypoint is. And determining this can be difficult too when you analyze malware.

To help you locate shellcode's entrypoint, or just find shellcode inside a file, scdbg has an option: -findsc.

As an example, I created a JPEG file that contains shellcode (not an exploit, the shellcode will not execute, it's just hidden inside a JPEG image).

Giving this file as input to scdbg using option -findsc does the following:

scdbg tries all possible entrypoints to the shellcode in this file, and then reports entrypoints (offsets) that lead to emulations that resulted in a Win32 API call or a long execution (many steps).

In the screenshot above, we see that scdbg found 6 offsets (numbered 0 through 5). Entry 0 looks promising (offset 0x7C2), as this lead to the call of MessageBoxA.

scdbg then prompts for the index of the shellcode's offset to emulate. I select 0 and get the following result:

This is indeed shellcode that was found at position 0x7C2: it displays a message box and then terminates the host process.

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

The PCAP[1] file format is everywhere. Many applications generate PCAP files based on information collected on the network. Then, they can be used as evidence, as another data source for investigations and much more. There exist plenty of tools[2] to work with PCAP files. Common operations are to anonymize captured traffic and replay it against another tool for testing purposes (demos, lab, PoC).

When you anonymize PCAP files, the goal is to replace IP addresses by other ones (The classic operation is to replace the first byte with a ’10’ value to make the IP address non-routable). However, the payload may contain sensitive data that are more difficult to sanitize. Last week, I attended the hack.lu[3] conference in Luxembourg and, during the lightning talks session, an interesting tool was demonstrated: pCraft. It can be described as a “PCAP file generator from a scenario described in YAML[4]”. The idea behind this tool is to create a scenario of network actions that will be translated into a fully-working PCAP file. 

Here is a quick example to demonstrate how to test an IDS rule:

start: GenerateNewDomain

GenerateNewDomain:
  _plugin: GenerateNewDomain
  _next: DNSConnection

DNSConnection:
  _plugin: DNSConnection
  sleep: {"once-finished": 1}
  _next: HTTPConnection

HTTPConnection:
  _plugin: HTTPConnection
  method: GET
  uri: "/shell?busybox"
  user-agent: "Mozilla/5.0"
  _next: done

The script is easy to understand: We generate a random domain name, we resolve it then we generate an HTTP request to the servers with a suspicious URI.

Let's generate the PCAP file:

# ./pcraft.py test.yaml test.pcap
['PCraft/plugins/HTTPConnection.py', 'PCraft/plugins/DNSConnection.py', 'PCraft/plugins/TcpRst.py', 'PCraft/plugins/HTTPPostConnection.py', 'PCraft/plugins/PcapImport.py', 'PCraft/plugins/Ping.py', 'PCraft/plugins/GenerateNewDomain.py', 'PCraft/plugins/Cheat.py', 'PCraft/plugins/SMTPReceive.py']
All plugins loaded!
Opening Script File test.yaml
[2019-10-28 18:01:35.324952] Executing: Generate_a_new_domain
[2019-10-28 18:01:35.367461] Executing: DNSConnection
[2019-10-28 18:01:35.368882] Executing: HTTPConnection
[2019-10-28 18:01:36.984010] Executing: done

The PCAP file can now be used to test our IDS or any other application.

Let's open it in a Wireshark and inspect the HTTP request:

pCraft is written in Python and, if you check the required modules, you see it relies on scapy[5] to generate packets and the PCAP file. Not many types of traffic are supported at the moment but, being based in plugins, it's easy to expand it. The current list of plugins is:

• DNSConnection
• GenerateNewDomain
• HTTPConnection
• HTTPPostConnection
• PCAPImport
• Ping
• TcpRst

pCraft has been developed by Sébastien Tricaud and is available on github[6]. Great tool!

[1] https://wiki.wireshark.org/Development/LibpcapFileFormat
[2] https://n0where.net/best-pcap-tools
[3] https://2019.hack.lu/
[4] https://en.wikipedia.org/wiki/YAML
[5] https://scapy.net/
[6] https://github.com/DevoInc/pCraft

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

BEC or "Business Email Compromize" is a trending thread for a while. The idea is simple: a corporate mailbox (usually from a C-level member) is compromized to send legitimate emails to other employees or partners. That's the very first step of a fraud that could have huge impacts.

This morning, while drinking some coffee and reviewing my logs, I detected a peak of rejected authentications against my mail server. There was a peak of attempts but also, amongst the classic usernames, bots tested some interesting alternatives. If the username is "firstname", I saw attempts to log in with:

firstname
okfirstname
mailfirstname
emailfirstname
firstnamemail
domain_firstname
...

And also the classic generic mailboxes ('noreply', 'info', webmaster', 'admin', etc)

The peak of activity was interesting:

Email remains an easy attack vector and is often very easy to compromise. Access to a corporate mailbox can be disastrous based on what people store in their mailbox (documents, passwords, pictures, etc) and mail servers remain often available in the wild. Keep an eye on remote accesses to mailboxes, especially for sensitive accounts! (Do you remember my diary about considering people as IOC's?[1])

[1] https://isc.sans.edu/forums/diary/May+People+Be+Considered+as+IOC/25166/

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

I’ve recently come across interesting behavior of Office 365 when EML files are attached to e-mail messages, which can be useful for any red teamers out there but which can potentially also make certain types of phishing attacks more successful.

Office 365, just like any other e-mail gateway with security features, uses a number of complex anti-phishing mechanisms and filters to catch malicious messages. This means that if we try to send an e-mail to a “Target User” which looks like a message from Paypal, but the embedded link points to a phishing site, O365 will correctly identify it as phishing/spam and catch it. The following example, where the link points to playplall.com, instead of paypal.com, illustrates this behavior nicely.

Before we move forward, let’s take a quick look at EML files. These are used to save e-mail messages by many e-mail clients (AKA Mail User Agents) and even Outlook and most other e-mail clients, which do not use EML as the default format for saving messages, at least have the ability to open and display them. EML files have a very simple internal structure – EML is basically just a MIME standard e-mail saved in a text file – and therefore an arbitrary one may be crafted quite easily as the following example shows.

MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
Date: Thu, 31 Oct 2019 10:29:47 +0100
From: Dracula <dracula@transylvania.ro>
To: Jan Kopriva <jan.kopriva@domain.tld>
Subject: Halloween


Hi Jan,
<br><br>
Just wanted to let you know I'll see you tonight... ;)
<br><br>
Count

This is the reason why e-mail gateways are sometimes configured to either mark messages containing EML attachments as potentially dangerous, scan such attachments or block them outright. Office 365 seems to do an anti-malware scan of EML attachments, but it doesn’t run them through anti-phishing filters… And you can probably see where this is heading.

If we were to craft an EML with the same contents as the first e-mail we looked at (which O365 caught as phishing) and sent it as an attachment, it would get through. If we put a text along the lines of “We’ve noticed you didn’t respond to our original message, so we’re sending it to you again” in the body of the main e-mail, there is quite a good chance that the intended recipient would at least open the attached EML.

But it gets better than that – nothing is stopping us from changing the sender in the EML to a legitimate Paypal (or other) address. The same EML may, of course, bypass other e-mail security gateway scans as well, depending on how they are configured. But with O365, here is (at least to my mind) the best part – if we send such an e-mail, as soon as our Target User opens the attachment in O365, Outlook will helpfully even put a Paypal logo next to the sender address. Thanks to this, the message really starts to look trustworthy.

I’ve informed Microsoft of this behavior of O365 and since they usually don’t consider similar behavior a vulnerability, the reply I got from them was exactly the one I expected (i.e. “Unfortunately your report appears to rely on social engineering to accomplish, which would not meet the bar for security servicing”).

Although I don’t assume that attackers will start using this technique en masse, I would still recommend considering automatically marking e-mail messages with EML attachments as potentially dangerous and adding a short warning about the potential risks of EML attachments into end-user security/phishing awareness courses.

If you find this technique interesting and would like to take a closer look at couple of others, consider joining us for a talk dedicated to this subject at SANSFIRE 2020 – we will go through many more tricks and techniques, some of which are not (yet) used in the wild.

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

Posted by InfoSec News on Nov 01

Posted by InfoSec News on Nov 01

Posted by InfoSec News on Nov 01