Snort Rule - Picking up Malware from AP (MR33)

SOLVED
AdrianL
Conversationalist

Snort Rule - Picking up Malware from AP (MR33)

Hi All,

 

New to Meraki and the forum so please be gentle 🙂

 

Had SNORT pick this up the other night, apparently originating from one of our AP's as the client -> destination was public external DNS servers 1.1.1.1 and 1.0.0.1.

 

MALWARE-CNC Win.Trojan.Zeus v3 DGA DNS query detected

 

Have i misread this?

 

Thoughts greatly appreciated.


Cheers,
Adrian

1 ACCEPTED SOLUTION
BrechtSchamp
Kind of a big deal

Well, it might be triggering on a DNS request originally coming from a client. But if the AP is proxying it to the DNS server (like for example when an SSID is in NAT-mode). So to the MX it seems like it came from the AP.

 

Now the question is, is it harmful. DGA (domain generation algorithms) are a technique of hiding malicious servers for which UTM devices already know the domain name behind temporary other domainnames, hereby circumventing protection mechanisms.

 

1.1.1.1 and 1.0.0.1 are the cloudflare DNS servers so that's not an issue. The issue probably was the dns name being resolved for which it seems you have no details?

View solution in original post

5 REPLIES 5
BrechtSchamp
Kind of a big deal

Well, it might be triggering on a DNS request originally coming from a client. But if the AP is proxying it to the DNS server (like for example when an SSID is in NAT-mode). So to the MX it seems like it came from the AP.

 

Now the question is, is it harmful. DGA (domain generation algorithms) are a technique of hiding malicious servers for which UTM devices already know the domain name behind temporary other domainnames, hereby circumventing protection mechanisms.

 

1.1.1.1 and 1.0.0.1 are the cloudflare DNS servers so that's not an issue. The issue probably was the dns name being resolved for which it seems you have no details?

PhilipDAth
Kind of a big deal
Kind of a big deal

The advantage of using NAT mode is you don't need to configure any additional VLANs and it is quite easy to setup guest WiFi.  The downside is it hides the actual clients from an MX.

 

I tend to use bridge mode and configure a VLAN because of this where I can.

Thanks Gents,
Ok that makes sense - as I do have several SSID's in NAT mode, and only a few light users which is probably why I have seen this for the first time. - as I thought that this was going to be the best way to isolate the users from (a) anyone else on the SSID and (b) the LAN.


Will have re-think this strategy - as I do need to be able to isolate the users, so will split them out via VLAN - which wasn't my preference.

Didn't see anything in the events log for either the AP or MX and unfortunately I didn't have the syslog running (fixed now), I suspect that this might have given me the address it was trying to resolve?

Is this the only way to get detailed security detail?


Thanks and appreciate the quick response.

Cheers,
Adrian

From the security center you should be able to get more details, you actually have access to the packet:

2019-02-15 15_44_49-Security Center - Meraki Dashboard.png

Thanks for that I didn't realize that you got that extra option  under the events tab - thank you for that.

 

 

8ccd32475fa16ffddb643b6c52c6f36761b55ef2.info. IN A

 

This is the info I got in the packet - will have a crack at decoding it tomorrow, as not something I have done before.

 

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels