Discussion:
Finding account given message ID
(too old to reply)
Jim Mack
2009-03-31 22:28:58 UTC
Permalink
Hi -

I wonder if anyone can articulate a strategy for locating a source of
spam originating from our E2K server.

Someone has hijacked an account on the server and is using it to
originate UCE/UBE floods.

We can determine (through bounces and NDRs) some of the message IDs,
but no one here knows a way to track those back to the original
account that created the message, so we can disable that account.

Any help? 'Cause if you don't, for sure we'll be sending you some
spam... (-:
--
Jim
Lanwench [MVP - Exchange]
2009-04-01 12:52:39 UTC
Permalink
Post by Jim Mack
Hi -
I wonder if anyone can articulate a strategy for locating a source of
spam originating from our E2K server.
Someone has hijacked an account on the server and is using it to
originate UCE/UBE floods.
We can determine (through bounces and NDRs) some of the message IDs,
but no one here knows a way to track those back to the original
account that created the message, so we can disable that account.
Any help? 'Cause if you don't, for sure we'll be sending you some
I don't have E2k here to check with, but can't you type the message-ID into
the Message Tracking center in ESM to find out more info about it?

NB: Exchange 2000 is long out of support and is pretty limited - your
company really needs to plan an upgrade/migration.
Jim Mack
2009-04-01 14:43:40 UTC
Permalink
Post by Lanwench [MVP - Exchange]
Post by Jim Mack
Hi -
I wonder if anyone can articulate a strategy for locating a source
of spam originating from our E2K server.
Someone has hijacked an account on the server and is using it to
originate UCE/UBE floods.
We can determine (through bounces and NDRs) some of the message
IDs, but no one here knows a way to track those back to the
original account that created the message, so we can disable that
account.
Any help? 'Cause if you don't, for sure we'll be sending you some
I don't have E2k here to check with, but can't you type the
message-ID into the Message Tracking center in ESM to find out more
info about it?
Lots of info, but unless it's hidden somewhere, not the account used
to create it. We used that to discover and block the external IP where
it was originating, but you can imagine how long that lasted.

Are there are any logging options that would help? We can turn on
exhaustive logging for a limited time if there's something that would
help us focus our search.
Post by Lanwench [MVP - Exchange]
NB: Exchange 2000 is long out of support and is pretty limited -
your company really needs to plan an upgrade/migration.
OK. I guess we'd first have to 'plan' some money. (-:
--
Jim
Mark Arnold [MVP]
2009-04-01 18:57:44 UTC
Permalink
You wouldn't get the account from the message ID. You'd get the
mailbox it was sent from but that's not the same thing and there is no
correlation between the account and the mesage id.
You can see who had permissions over the mailbox (in addition to the
account that owns it obviously) but you can't do that retrospectively.
Jim Mack
2009-04-01 20:52:41 UTC
Permalink
Post by Mark Arnold [MVP]
You wouldn't get the account from the message ID. You'd get the
mailbox it was sent from but that's not the same thing and there is
no correlation between the account and the mesage id.
You can see who had permissions over the mailbox (in addition to the
account that owns it obviously) but you can't do that
retrospectively.
This setup allows outside SMTP after authentication, so if an account
is compromised you don't really know enough if all you know is the
accessing IP. We need to discover which mailbox they're coming in
through.

What strategy would you use to locate the compromised account in these
circumstances?
--
Jim
Lanwench [MVP - Exchange]
2009-04-01 23:28:12 UTC
Permalink
Post by Jim Mack
Post by Mark Arnold [MVP]
You wouldn't get the account from the message ID. You'd get the
mailbox it was sent from but that's not the same thing and there is
no correlation between the account and the mesage id.
You can see who had permissions over the mailbox (in addition to the
account that owns it obviously) but you can't do that
retrospectively.
This setup allows outside SMTP after authentication, so if an account
is compromised you don't really know enough if all you know is the
accessing IP. We need to discover which mailbox they're coming in
through.
What strategy would you use to locate the compromised account in these
circumstances?
Disable authenticated relay and this problem will go away. As Mark said, it
is unlikely you'll be able to do much in the way of useful forensics work.

PS: Re money, did you look under the couch cushions?
Jim Mack
2009-04-02 01:00:23 UTC
Permalink
Post by Lanwench [MVP - Exchange]
Post by Jim Mack
This setup allows outside SMTP after authentication, so if an
account is compromised you don't really know enough if all you
know is the accessing IP. We need to discover which mailbox
they're coming in through.
What strategy would you use to locate the compromised account in
these circumstances?
Disable authenticated relay and this problem will go away. As Mark
said, it is unlikely you'll be able to do much in the way of useful
forensics work.
Right. If that would be plan A, what's plan B? There are enough
people with say-so who depend on being able to send mail through the
server from home and on the road. Politically, plan A isn't possible.

We've turned on exhaustive logging, and out of that should fall any
heavy senders. The typical user of this system might send 20 messages
a day -- anything a lot higher is going to be a red flag.
Post by Lanwench [MVP - Exchange]
PS: Re money, did you look under the couch cushions?
Yep. Came up about $3000 short. (-:
--
Jim
Lanwench [MVP - Exchange]
2009-04-02 02:37:18 UTC
Permalink
Post by Jim Mack
Post by Lanwench [MVP - Exchange]
Post by Jim Mack
This setup allows outside SMTP after authentication, so if an
account is compromised you don't really know enough if all you
know is the accessing IP. We need to discover which mailbox
they're coming in through.
What strategy would you use to locate the compromised account in
these circumstances?
Disable authenticated relay and this problem will go away. As Mark
said, it is unlikely you'll be able to do much in the way of useful
forensics work.
Right. If that would be plan A, what's plan B? There are enough
people with say-so who depend on being able to send mail through the
server from home and on the road. Politically, plan A isn't possible.
Aww, sure it is. Your remote users can use VPN or OWA or various other
methods. I don't allow authenticated relay on any of my clients' networks
and that's mainly for the reason you're finding yourself in here now. This
is not a political issue. It's a security one which can be neatly resolved
by technical means. Or: the powers that be, once this has been explained in
small words, can decide they don't care if their server is exploited in this
manner, and you can go about your business (after getting this in writing
from them).
Post by Jim Mack
We've turned on exhaustive logging, and out of that should fall any
heavy senders. The typical user of this system might send 20 messages
a day -- anything a lot higher is going to be a red flag.
OK. You may find it. I don't know.
Post by Jim Mack
Post by Lanwench [MVP - Exchange]
PS: Re money, did you look under the couch cushions?
Dang. Let me know if you find the DVD remote.
Jim Mack
2009-04-02 14:04:23 UTC
Permalink
Post by Lanwench [MVP - Exchange]
Post by Jim Mack
Post by Lanwench [MVP - Exchange]
Disable authenticated relay and this problem will go away. As Mark
said, it is unlikely you'll be able to do much in the way of
useful forensics work.
Right. If that would be plan A, what's plan B? There are enough
people with say-so who depend on being able to send mail through
the server from home and on the road. Politically, plan A isn't
possible.
Aww, sure it is. Your remote users can use VPN or OWA or various
other methods. I don't allow authenticated relay on any of my
clients' networks and that's mainly for the reason you're finding
yourself in here now. This is not a political issue. It's a
security one which can be neatly resolved by technical means.
Easy to say, sitting up there all comfy in the LanWench Tower. Not so
easy down in the trenches. Knowing what's best and doing it can be
miles (& dollars) apart.

Many of the users do come in through OWA, but that isn't an option for
a lot of mobile users (tried OWA on your Verizon phone?), and some --
the ones with the budgets -- uust want POP/IMAP/SMTP via Thunderbird
etc.

Still, if they can't get a handle on it soon, you're right that they
face the tough decision of letting it continue, and be shamed for it,
or changing their expectations.

Thanks for your help, in any case.
--
Jim
Mark Arnold [MVP]
2009-04-02 14:26:27 UTC
Permalink
Post by Jim Mack
Post by Lanwench [MVP - Exchange]
Post by Jim Mack
Post by Lanwench [MVP - Exchange]
Disable authenticated relay and this problem will go away. As Mark
said, it is unlikely you'll be able to do much in the way of
useful forensics work.
Right. If that would be plan A, what's plan B? There are enough
people with say-so who depend on being able to send mail through
the server from home and on the road. Politically, plan A isn't
possible.
Aww, sure it is. Your remote users can use VPN or OWA or various
other methods. I don't allow authenticated relay on any of my
clients' networks and that's mainly for the reason you're finding
yourself in here now. This is not a political issue. It's a
security one which can be neatly resolved by technical means.
Easy to say, sitting up there all comfy in the LanWench Tower. Not so
easy down in the trenches. Knowing what's best and doing it can be
miles (& dollars) apart.
Many of the users do come in through OWA, but that isn't an option for
a lot of mobile users (tried OWA on your Verizon phone?), and some --
the ones with the budgets -- uust want POP/IMAP/SMTP via Thunderbird
etc.
Still, if they can't get a handle on it soon, you're right that they
face the tough decision of letting it continue, and be shamed for it,
or changing their expectations.
Thanks for your help, in any case.
It's not that comfortable in Lanwench towe any morer; Bernie Maddoff
used to be their client and the whole yacht at weekend thing just
ended.
Jim Mack
2009-04-02 17:58:31 UTC
Permalink
Post by Mark Arnold [MVP]
It's not that comfortable in Lanwench towe any morer; Bernie Maddoff
used to be their client and the whole yacht at weekend thing just
ended.
Hmmm... I can see a movie for our age: "Weekend at Bernie Madoff's"
--
Jim
Lanwench [MVP - Exchange]
2009-04-03 01:25:07 UTC
Permalink
Post by Jim Mack
Post by Mark Arnold [MVP]
It's not that comfortable in Lanwench towe any morer; Bernie Maddoff
used to be their client and the whole yacht at weekend thing just
ended.
Hmmm... I can see a movie for our age: "Weekend at Bernie Madoff's"
I now feel most fortunate for never having had the inclination to invest
money ... nor the money to invest in anything.
Lanwench [MVP - Exchange]
2009-04-03 01:24:23 UTC
Permalink
Post by Jim Mack
Post by Lanwench [MVP - Exchange]
Post by Jim Mack
Post by Lanwench [MVP - Exchange]
Disable authenticated relay and this problem will go away. As Mark
said, it is unlikely you'll be able to do much in the way of
useful forensics work.
Right. If that would be plan A, what's plan B? There are enough
people with say-so who depend on being able to send mail through
the server from home and on the road. Politically, plan A isn't
possible.
Aww, sure it is. Your remote users can use VPN or OWA or various
other methods. I don't allow authenticated relay on any of my
clients' networks and that's mainly for the reason you're finding
yourself in here now. This is not a political issue. It's a
security one which can be neatly resolved by technical means.
Easy to say, sitting up there all comfy in the LanWench Tower. Not so
easy down in the trenches. Knowing what's best and doing it can be
miles (& dollars) apart.
Ha ha ha. Pass me another bonbon. I don't want to smudge my nails. Now,
where is that boy with my cappuccino?
Post by Jim Mack
Many of the users do come in through OWA, but that isn't an option for
a lot of mobile users (tried OWA on your Verizon phone?), and some --
the ones with the budgets -- uust want POP/IMAP/SMTP via Thunderbird
etc.
OK. Well, I don't think it's the users' business to dictate to IT what
they'll use, but I know what you're up against. I suggest you make your
objections clearly known in an email or memo - and hang onto it.
Post by Jim Mack
Still, if they can't get a handle on it soon, you're right that they
face the tough decision of letting it continue, and be shamed for it,
or changing their expectations.
Thanks for your help, in any case.
No prob and best of luck. I'll just get back into my silk-upholstered sedan
chair now.

Loading...